| layout | title | date | categories |
|---|---|---|---|
post |
Азы проектирования схемы данных |
2017-07-11 15:49:55 +0300 |
databases development |
Для того, чтобы быть нормальным разработчиком, надо (уверен) среди прочего принимать и понимать следующие истины:
- Программы создаются для работы с данными. Без данных нет программы, нет пользы. Данные — основа всего.
- Без хорошо спроектированной схемы данных в базе данных говорить о качестве продукта нет смысла.
- Проектирование — задача, при решении которой учитываются не только текущие и сиюминутные требования, но также и требования, что могут возникнуть.
Искренне считаю, что у желающего оспорить эти три утверждения как были проблемы, так и будут.
Также на фоне современности с её NoSQL следует понимать и такое: у вас нет schemaless database, оставьте этот термин маркетологам. Ещё на заре изучения таких баз в учебниках писали, что схема с database level перешла на application level. Перешла. Не пропала. А если вы с азартом используете ту же MongoDB в режиме грабьубивай, в итоге обязательно окажется, что грабилиубивали себя же. Исключений не видел, зато читал миллиард рассказов о том, как всё заканчивалось плохо.
И последнее стратегическое правило. Относится к голове. Вы проектируете контейнер для данных, который позволит удобно оперировать этими данными. Вы НЕ решаете конкретную задачу. НИКОГДА, блин, не решайте только одну конкретную задачу в этой области. Вот аналогией ща.
Дано: деревенская семья выращивает груши, нуждается в ящиках для хранения и транспортировки. Вы такой ящик проектируете. Что разумное существо прикинет?
Во-первых, делать ящик именно для груш... нет. Завтра посадят яблони, послезавтра персики. И что, устраиваем зоопарк и конкурсы проектировщиков? Помните, что источники данных для ваших таблиц / коллекций со временем будут меняться. Не кардинально, но шаг влево-вправо всегда будет. Потому так же шатайте требования, старайтесь проектировать хранение для класса (фрукты), а не для экземпляра (груши).
Во-вторых, фруктов будет много. То, что сейчас вам кажется (или по ТЗ), что ящика достаточно... ваше "кажется" значит ровно ноль. Делайте ящик с учётом следующего: груш будет миллион, яблок пара сотен тысяч, и даже два мешка огурцов сбоку. Сегодня выращивает одна семья, завтра колхоз, послезавтра корпорация (в контексте ящиков это означает, что следует предусмотреть удобство хранения ящиков на складах, транспортировку сухогрузами и т.д.). Ваше решение должно быть масштабируемым "горизонтально". Типичная и обычная ошибка проектировщика заключается в недооценке количества данных. В худшем случае это приводит к написанию приложения с нуля. В обычном случае это приводит к нагромождению костылей, лишь бы запрос работал не сутки. Проверяйте свои идеи на миллионах, десятках миллионов строк / документов. Влейте синтетические данные и доведите базу до смерти, чтобы выяснить реальный практический предел. Он же и будет пределом применимости того, что вы сделали.
В-третьих, поставьте себя на место крестьянина. Для чего ему нужен ящик? Какие операции будут проводиться в первую очередь? Поднять, поставить, перенести, утилизировать, починить. Какие операции могут понадобиться? До чего крестьянин / колхоз / корпорация могут дойти через год? А через два? Так же и с базой. Как минимум, надо учесть все базовые кейсы (тут уже зависит от вашей головы, опыта и знаний). Не должно быть проблемой отработать MIN / MAX. Не должны JOIN'ы с поставщиками яблок выполняться часами. Фруктовая сумма за пять лет не должна укладывать базу на пол. Поймите следующее: были бы данные, а запросы найдутся. То, что сейчас крестьянин не будет делать аналитические срезы по грушам, вовсе не значит, что в будущем аналитики корпорации не захотят годовых отчётов. Ваша задача в том, чтобы это уже сейчас работало быстро и правильно. Тех, кто говорит "этого не будет", к проектированию не подпускайте. Будет ВСЁ.
Резюмирую:
- Проектировать под решение класса задач, а не задачи.
- Проектировать масштабируемое решение.
- Проектировать не вещь в себе, но с учётом кейсов как обычных [для всех баз], так и текущих пользовательских, так и будущих.
Отдельная и часто забываемая тема — удобство интеграции и сопровождения. Вы спроектируете отличную схему данных и получите через год ворох проклятий, если забудете, что в мире существует нужда в миграции данных, в удобстве для ORM, в дампах (их размере), в создании и в удалении схемы. Также существуют некоторые гигиенические нормы вроде нормализации. Вас очень будут любить разработчики, которые через год обнаружат, что в ряде таблиц данные рассинхронизировались и потому в одном случае у Пети два сына, а в другом собачка. Такими косяками обычно страдают не занимавшиеся разработкой проектировщики. Не надо такими быть.
Вот как-то так. Конечно, в идеале проектированием схем занимаются те, кто этим умеет заниматься, да ещё и теорию подкачал, но на практике зачастую этим занимаются по случаю и мимоходом. Если вы из этой категории, всё-таки попробуйте применить описанное выше. Даже если одно правило поможет, уже кому-нибудь однажды подарите спокойную ночь.