Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.

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

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

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

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

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

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

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

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

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