дизайн схемы

Question

Скажем, вы GM dba, и вы должны разрабатывать модели GM

Это лучше сделать?

• table_model
  • type {cadillac, saturn, chevrolet}

Или это?

• table_cadillac_model
• table_saturn_model
• table_chevrolet_model

Скажем, бизнес-линии имеют одинаковые столбцы для модели и для каждого подтипа существует более миллиона записей.

EDIT:

• много CRUD
• есть много очень ресурсоемких отчетов
• в любой схеме есть таблица model_detail, которая содержит 3-5 записей для каждой модели, и детали для каждой модели различаются (вы не можете добавить детали cadillac в модель сатурна)
• Команда разработчиков не имеет проблем со сложностью БД
• Я не совсем уверен, что это вопрос нормализации. даже если структуры одинаковы, их можно рассматривать как разные объекты.

EDIT:

Причины разделения структуры на несколько таблиц - бизнес-линии могут иметь разные бизнес-правила в отношении частей - addModelDetail () может отличаться для каждой бизнес-линии (даже если формат данных один и тот же) - высокая активность добавления / обновления - лучшая производительность с разделенной структурой, а не с одной структурой (я предполагаю и не уверен здесь)?

Я думаю, что это вариация проблемы EAV. При представлении в качестве структуры EAV структура единой таблицы обычно считается плохой идеей. При таком подходе единый табличный конструктор, как правило, считается хорошей идеей. Интересно ...

Я думаю, что самый интересный ответ - это две разные структуры - одна для грубой и одна для отчетности. Я думаю, что я попробую объединенное / плоское представление для отчетов и несколько таблиц для crud и посмотрю, как это работает.

Answer 1

Определенно первый пример. Хотите ли вы добавлять таблицы в свою базу данных всякий раз, когда добавляете новую модель в свой ассортимент?

Answer 2

Для данных с большим количеством записей (например, приложение OLTP) лучше иметь больше, более узкие таблицы (например, таблицы с меньшим количеством полей). Будет меньше конфликтов с блокировками, потому что вы записываете только небольшие объемы данных в разные таблицы.

Итак, исходя из критериев, которые вы описали, структура таблицы, которую я хотел бы иметь:

Vehicle
  VehicleType
  Other common fields

CadillacVehicle
  Fields specific to a Caddy

SaturnVehicle
  Fields specific to a Saturn

Для составления отчетов у меня была бы совершенно другая база данных на совершенно другом сервере, который не имеет нормализованной структуры (например, только таблицы CadillacVehicle и SaturnVehicle со всеми полями из таблицы Vehicle, дублированными в них).

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

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

Answer 3

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

Answer 4

Я бы сказал, что первый способ выглядит лучше.

Есть ли причины, по которым вы хотели бы сделать это вторым способом?

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

Второй способ сложнее поддерживать.

Если нет действительно веской причины сделать это вторым способом, я бы пошел с первым методом.

Answer 5

Вы можете попробовать иметь две отдельные базы данных.

Одна из них - система OLTP (OnLine Transaction Processing), которая должна быть строго нормализована, чтобы модель данных была в высшей степени корректной. Производительность отчетов не должна быть проблемой, и вы будете иметь дело с производительностью запросов без отчетов с индексами / денормализацией и т. Д. В каждом конкретном случае. Модель данных должна стараться очень близко соответствовать концептуальной модели.

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

Answer 6

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

Answer 7

@ mson задал вопрос «Что вы делаете, когда на вопрос SO не дан удовлетворительный ответ? », что является прямой ссылкой на существующие ответы на этот вопрос.

Я дал следующий ответ на это обсуждение, в первую очередь критикуя способ, которым был задан вопрос.

---

Цитата (дословно):

Я вчера посмотрел на исходный вопрос и решил не давать ответа.

Одной из проблем было использование термина «модель», как в «моделях GM», в котором «Шевроле, Сатурн, Кадиллак» назывались «моделями». Насколько я понимаю, это не модели вообще; они являются «брендами», хотя для них также может существовать отраслевой термин, которым я не знаком, например «подразделение». Модель будет «Сатурн Вю» или «Шевроле Импала» или «Кадиллак Эскалад». Действительно, вполне могли бы быть модели на более детальном уровне - например, различные варианты Saturn Vue.

Итак, я не думал, что отправная точка была хорошо сформулирована. Я не критиковал это; это не было достаточно убедительным, и были ответы, поэтому я позволил другим людям попробовать это.

Следующая проблема заключается в том, что неясно, что ваша СУБД будет хранить в качестве данных. Если вы храните миллион записей на «модель» («бренд»), то с какими типами данных вы имеете дело? На заднем плане скрывается другой сценарий - реальный сценарий - и ваш вопрос использовал аналогию, которая не была достаточно реалистичной. Это означает, что части ответа «все зависит» гораздо более обширны, чем «как это сделать». К сожалению, слишком мало справочной информации о данных для моделирования позволяет нам угадать, что может быть лучше.

В конечном счете, это будет зависеть от того, как люди используют данные. Если информация будет разлетаться во всех разных направлениях (разные структуры данных у разных брендов; разные структуры данных на уровнях моделей автомобилей; разные структуры для разных дилерских центров - с дилерами Chevrolet обращаются по-разному, чем с дилерами Saturn и Cadillac дилеры), то интегрированная структура дает ограниченную выгоду. Если все до конца одинаково, то интегрированная структура дает много преимуществ.

Существуют ли правовые причины (или преимущества) для разделения данных? В какой степени разные бренды являются отдельными юридическими лицами, где совместные записи могут быть ответственностью? Существуют ли проблемы с конфиденциальностью, так что будет проще контролировать доступ к данным, если данные для отдельных брендов хранятся отдельно?

Без более подробной информации о моделируемом сценарии никто не может дать надежный общий ответ - по крайней мере, не больше, чем тот, кто уже проголосовал за него (или не дает).

• Моделирование данных непросто.
• Моделирование данных без достаточной информации невозможно сделать надежно.

---

Я скопировал материал здесь, так как он более актуален. Я думаю, что для удовлетворительного ответа на этот вопрос необходимо дать гораздо больше контекста. И вполне возможно, что должно быть достаточно дополнительного контекста, чтобы сделать ТА неправильное место, чтобы спросить его. У SO есть свои ограничения, и одним из них является то, что он не может решать вопросы, требующие длинных объяснений.

Со страницы часто задаваемых вопросов SO:

Какие вопросы я могу задать здесь?

Вопросы программирования, конечно! Пока ваш вопрос:

• подробный и конкретный
• написано ясно и просто
• представляет интерес хотя бы для одного другого программиста где-то

...

Какие вопросы мне не следует задавать здесь?

Старайтесь не задавать вопросы, которые носят субъективный, аргументативный характер или требуют расширенного обсуждения. Это место для вопросов, на которые можно ответить!

Этот вопрос, IMO, близок к пределу ' требует расширенного обсуждения '.

Answer 8

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

Да, и под "бывшим" мы подразумеваем эту опцию:

table_model
* type {cadillac, saturn, chevrolet}

Answer 9

Выбор зависит от требуемой производительности. Лучшая база данных - нормализованная база данных. Но могут быть проблемы с производительностью в нормализованной базе данных, тогда вам придется ее денормализовать Принцип «нормализуй сначала, денормируй для производительности» работает хорошо.

Answer 10

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

Я согласен с двумя другими людьми, которые ответили: какая форма «лучше», субъективна и зависит от того, чего вы надеетесь достичь. Если вы надеетесь получить очень быстрые запросы, это одно. Если вы надеетесь достичь высокой производительности труда программиста - это снова другая цель и, возможно, конфликт с быстрыми запросами.