Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Мы довольно много говорили о теории реляционных баз данных, затронули такие темы как: связи между сущностями, ключи и ключевые атрибуты, нормальные формы. Я старался объяснять все эти вопросы на простых и понятных примерах, не используя математики, на которой базируется реляционная теория баз данных. Возможно, это даже упущение. Но, теперь я могу утверждать, что вы спокойно можете проектировать базы данных, поскольку у вас есть фундамент — теория реляционных баз данных.

Теория – это хорошо, если то, что я излагал у вас будет подкреплено математикой – еще лучше, но у вас никогда не получится грамотно, (подчеркну слово грамотно), спроектировать базу данных без изучения предметной области и процессов, которые в ней происходят. Только изучив предметную область можно быть уверенным, что в итоге получится что-то годное.

Мы вооружились теорией, у нас есть детальное представление о предметной области, но, к сожалению, в нашем мире нет ничего идеального. Не идеальны люди, компьютеры, на которых они работают, не идеально программное обеспечение. Повторюсь: ни один стандарт SQL не соответствует полностью РТБД и нет в мире ни одной СУБД, которая полностью бы соблюдала хотя бы один из стандартов SQL. Поэтому проектирование баз данных это всегда компромисс. Это всегда поиск решений, это выбор между целостностью данных и скоростью работы приложения.  Например, в 8 части данной темы я сознательно не стал проводить нормализацию адресов. Зачем мне приводить к третьей нормальной форме адреса издательств, если эта база данных библиотеки или небольшого книжного магазина? Но, если это база данных всех предприятий, на всей территории России, в которую вносятся все изменения, связанные с предприятием, то, наверное, имеет смысл сделать нормализацию адресов. Опять же, нужно смотреть на технические условия и потребности заказчика.

При проектировании баз данных очень здорово помогает не только теория, но и здравый смысл и логика, еще я бы добавил лень. Не стоит понимать лень, как нежелание написать комментарий или «10 лишних строк кода», на которые уйдет ровно пять минут. Если я что-то проектирую, я должен быть ленивым: я должен сделать всё быстро, потому что мне лень, поэтому я должен хорошо знать теорию и инструмент, которым я пользуюсь. Если я что-то делаю, то я должен сделать это качественно, чтобы потом не переделывать, поэтому мне необходимо изучить предметную область и обладать здравым смыслом при поиске компромиссов.

При проектировании баз данных нам нужно очень хорошо знать инструмент, которым мы пользуемся и обладать неким опытом (не обязательно в работе с базами данных). В нашем случае инструмент – это SQL и библиотека SQLite3. А по поводу опыта приведу несколько простых примеров: необязательно всю жизнь работать разработчиком, чтобы понять, что индексы, городов, телефонные номера, ISBN книг нужно хранить в текстовом или символьном виде (а не в числовом), достаточно изучить инструмент, которым мы будем пользоваться, чтобы понять почему (сделать поиск по тексту гораздо легче). Не обязательно быть мега-крутым проектировщиком баз данных, чтобы понять, что емкости жестких дисков ограничены и нужно трепетно подходить к выбору типов данных столбцов при проектировании баз данных, особенно, когда дело качается больших предприятий. Необязательно всю жизнь работать в IT сфере, чтобы понять, что стоимость изменений на этапе проектирования или разработки решений куда ниже, чем на этапе реализации проекта и, чем ближе к завершению, тем дороже обходятся изменения (как в финансовом, так и во временно аспекте).

Давайте подведем итог и сформируем необходимые для проектирования баз данных качества, навыки и знания:

  • знание теории баз данных (как минимум, ее фундамента);
  • знание предметной области;
  • навык работы с инструментом (SQL и СУБД);
  • обладать здравым смыслом и логикой, чтобы находить компромиссы.

Конечно, проектирование баз данных – кропотливое, ответственное и требующее от нас довольно широкого спектра знаний и умений занятие. Поэтому, зачастую, в более-менее серьезных предприятиях в этом процессе участвует несколько человек: один общается с клиентом и выясняет потребности, формируя ТЗ для другого, который спроектирует архитектуру, архитектор в свою очередь напишет ТЗ для третьего, который напишет SQL-запросы, четвертый соберет все это в одно целое, пятый протестирует. И этот цикл может повторяться и операций в этом цикле может быть гораздо больше.

Логика у нас есть, здравый смысл присутствует, теоретические знания заложены, осталось только изучить инструменты, которые позволят на практике создавать и проектировать базы данных. Про предметную область я ничего не говорю, поскольку это дело вашего вкуса и потребностей.

Возможно, эти записи вам покажутся интересными


Выберете удобный для себя способ, чтобы оставить комментарий

This article has 2 comments

  1. Юрий Reply

    «...необязательно всю жизнь работать разработчиком, чтобы понять, что индексы, городов, телефонные номера, ISBN книг нужно хранить в текстовом или символьном виде (а не в числовом), достаточно изучить инструмент, которым мы будем пользоваться, чтобы понять почему (сделать поиск по тексту гораздо легче).»

    Может быть поясните? Тут или в отдельной статье.

    • Кирилл Reply

      Причин много, на мой взгляд основные:

      1. Вы никогда не будете делать математические операции с этими данными.

      2. Используя текстовые типы данных вы сможете добавлять сразу такие символы:-)( и другие.

      3. Текстовый тип данных проще форматировать.

      4. В строке проще найти подстроку, чем в числе последовательность цифр, имхо.

      5. Индекс, например, может начинаться с нуля в типе INT первый ноль будет отброшен, а мы этого не хотим.

      6. Например, вы наполняете таблицу из файл автоматически и в какой-нибудь ячейки стоит значение NULL, некоторые СУБД этот NULL конвертируют в 0, если тип будет INT, если тип будет текстовый вы увидите NULL, для вас это будет означать что данных нет.

      Но у типа INT есть плюс — он занимает меньше места.

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Loading Disqus Comments ...