Как грамотно разработать базу данных?

Question

[vitovt]

Всегда при разработке нового проекта возникает вопрос как грамотно разработать базу данных в MySQL так что бы она хорошо справлялась с нагрузками и удобно было пользоваться. К примеру, есть пользователи, есть контактная инфа о пользователях, компания, привязки компаний к пользователям, транзакции, счета и т.д. ) может быть есть методика, статья, софт?

Answer 1

[SSoft]

1. Выделяем все необходимые сущности (объекты)
2. Определяем набор полей для сущностей
3. После того, как сущности созданы, производим их нормализацию — минимум к 3ей форме привести надо
4. Снова заглядываем в тех. задание и примерно накидываем возможные запросы, выделяем тяжелые запросы (те, которые тянут много данных, или которые жойнят много таблиц) и пытаемся переделать структуру БД так, чтобы упростились запросы. Здесь остановочка: чаще всего основными запросами являются SELECTы, но бывает что SELECT делается относительно редко и намного более важен быстрый INSERT данных, плясать надо отсюда.
5. Снова критически оцениваем структуру, и снова кидаем примерные запросы. Внимательно смотрим на INSERTы. Смотрим, какие INSERTы можно вынести в триггеры. Накидываем примерное тело триггера, рихтуем структуру под него
6. Снова критически оцениваем структуру, смотрим чего у нас не хватает. Пытаемся часть SELECTов вынести в View, а часть в хранимые процедуры
7. Снова критически оцениваем получившуюся кашу. Что-то поправляем, вспоминаем что мы упустили что-то ещё. Возвращаемся к пункту 3.
8. После того, как нам кажется что все сделано, описываем каждую таблицу и поле словами, подробно расписываем что и для чего мы сделали, где что оптимизировали и для чего.
9. На следующее утро смотрим снова свою структуру, ужасаемся. Вспоминаем что вчера сделали описание. Внимательно читаем, понимаем что мы упустили кое-что ещё. Поправляем, дополняем.
10. Несем структуру соседнему программисту и пытаемся ему объяснить flow of data. Когда до него наконец-то все дойдет, спрашиваем что бы он мог переделать. Он дает советы, после которых выдумаете что «это ведь было очевидно». Снова все переделываем.
11. Когда сосед-программист от вас устал и послал нахуй согласился с вашей структурой, открываем администратор БД, накидываем схему, проставляем ключи. Снова понимаем что что-то упустили. Снова переделываем структуру.
12. Измучанный и злой ложишься спать. Утро вечера мудренее :)

© me

Comments

[Masterkey]

замечание к 3. можно и к бойса-кодда

и общее замечание — нужно определить для себя: готовы ли вы разбросать логику приложения по хранилищу (бд) и по коду самого приложения. я лично для себя решил, что больше не хочу работать со смешанной структурой — ее слишком геморно поддерживать, а иногда очень сложно отследить изменения которые были произведены.
но такое решение приходит только после мучений.

удачи в проектировании!

[Владимир Чернышев]

По-моему, помещать логику в БД нужно не раньше, чем эта логика на стороне приложения станет узким местом. Прикинуть заранее можно, что можно поместить в БД и какой выигрыш это даст, но спешить не стоит, пока время реакции приемлемое, действительно поддержка в ад превращается. И даже когда будет неприемлемым, а других вариантов оптимизации уже не будет, всё равно ещё раз подумать, а не лучше ли заменить сервер и/или расширить кластер :)

Answer 2

[exaide]

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

Answer 3

[netAn]

Нас в ККЭП учили так:

• Предметная область. Описываем (лучше не в уме) простым русским языком — что мы моделируем. База данных всегда является моделью чего-то в реальности. Укрупненно основные объекты и связи между ними, без деталей. Инструмент — MS Word, notepad, Бумагаручкамозг.
• Создаем концептуальную модель. Уже можно порисовать рисунки в ворде.
• Далее идет логическая модель данных — в ней уже есть эмбрионы будущих таблиц, с именами полей и связями между ними. Тут уже указываем тип связей — 1:1, 1:n, m:n. Тут уже можно порисовать в простом графическом редакторе или на доске.
• Далее предпоследний этап — физическая модель данных, когда указываем типы полей. На этом этапе наименее мучительно использовать UML-схемы, например с помощью StarUML.
• И последний, но циклический этап — нормализация данных. Выясням, какие данные избыточны и повторяются, и выносим их в отдельную таблицу. На этом этапе уже можно подключать PHPMyAdmin или схожую утилиту и создавать непосредственно таблицы на сервере.
• Если перестарались — система может работать медленно, и можно кое-где сделать денормализацию. Тут уже помогут нагрузочное тестирование и опыт.
• ???????
• PROFIT

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

Comments

[Gluttton]

Позволю себе не согласиться:
1. Типы связей указываются уже на этапе концептуального проектирования.
2. Связей типа многие-ко-многим на этапе логического проектирования нет.
3. Типы полей (не понял, что это «типы данных полей» или «атрибуты» — не важно, т.к. справедливо для обоих случаев) указываются на этапе логического проектирования (более того, в первом приближении, они могут быть рассмотрены и на этапе концептуального проектирования).
4. Денормализация — далеко не единственный способ ускорить запросы, в первую очередь я бы обратил внимание на индексы, так же можно оптимизировать запрос (например не выбирать множество по условию из результатов соединения, а соединять результаты условия).

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

[netAn]

п.1 — спасибо, вы за меня доделали работу, я как раз забыл расшифровать у себя в комментариях термин «концептуальная модель». В остальном вы позволили себе не согласится совершенно по пустякам.
А постижение предметной области — это да, больное место проектирования.
На этой стадии эксперт в автоматизируемом процессе должен поделиться знаниями с программистом-проектировщиком. Иногда информацию приходится вытаскивать клещами и нечеловеческим терпением.

[Владимир Чернышев]

Методики две — нормализация при изначальном проектировании, денормализации после нагрузочного тестирования (а иногда и после первого запуска запроса :) ).

А вообще я заметил, что в последнее время перестал проектировать базу данных как таковую. Раньше очень часто с этого начинал новое приложение, а сейчас проектирую модель предметной области (сначала словами, потом диаграммами, прежде всего диаграммами классов), реализую эти классы на выбранном ЯП, а потом «тупо» дублирую (когда почти автоматически, когда ручками) в СУРБД класс как таблицу, объекты как строки, свойства как поля и забываю про БД, до тех пор, пока не приходит (если приходит) время заняться оптимизацией.

[Владимир Чернышев]

упс, не то нажал

Answer 4

[yetanotherape]

Думаю начать надо с выделения сущностей и нормализации. Исходя из запросов (хорошенько проексплейнив) следует расставить индексы. Если и этого не хватит — задуматься над денормализацией.

Answer 5

[evgenyk]

Картина неполная.
Где заказчик, который непременно хочет внедрить свои умные мысли в структуру таблиц/полей БД?

Comments

[Masterkey]

ну тогда добавьте еще ответственного за проект в крупной компании, который бегает к директору и согласовывает все с ним…
и заказчика, который в конце работы над тз говорит, что цена слишком высока…
и тд и тп.

[evgenyk]

Ну, у кого что болит, тот про то и говорит.
А еще бывает программисты с базовщиками тянут одеяло на себя, где реализовывать логику, то ли в классах, то ли в хранимые процедуры.

[Masterkey]

я просто так и не нашел нормального способа следить за версионностью изменений бд, в особенности, когда не дают делать рефакторинг (((

[Di Lee]

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

Answer 6

[afiskon]

Вот еще по теме eax.me/database-design

Answer 7

[vitovt]

Спасибо всем )