Несколько таблиц базы данных или объединены в одну

Question

У меня вопрос по архитектуре базы данных.

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

Я изо всех сил пытаюсь выбрать один из двух подходов

1) Есть таблица для каждого вида списка.Примером могут служить такие таблицы, как list_CrediStatus, list_Branches, list_Markets и т. Д.

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

2) Имеется две таблицы.Иметь таблицу описания, в которой вы можете определить все различные имена списков (list_CreditStatus, list_Branches и т. Д.). В другой таблице есть все значения всех списков плюс внешний ключ, который связывает каждую строку с ее идентификатором в таблице описания.

Преимущества - меньше таблиц, 1 запрос и унифицированный формат.Недостатки могут быть в производительности.Эта таблица должна быть запрошена много.В нем будет много строк и много данных.

У кого-нибудь есть совет?Я склоняюсь к варианту 2. Также дайте мне знать, если это не имеет смысла.Это был сложный вопрос, чтобы написать ясно.

Спасибо, Джед

Answer 1

Всегда держите как вещи в одной таблице и в отличие от вещей в отдельных таблицах. это означает, что вы выбираете вариант 1. Помните: поверхностное сходство, основанное на именах полей, не означает, что они похожи на вещи.

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

Кроме того, вы не можете использовать правильный внешний ключ. Как вы говорите, что ORDER имеет столбец CREDIT_STATUS, который ссылается на таблицу списка, не позволяя кому-либо добавить значение типа крови (или другого)?

Answer 2

Я бы имел таблицу для каждого типа.Зачем ?Среди прочих причин вы можете легко обнаружить, что эти типы данных постепенно накапливают дополнительную информацию , в частности для этого типа.Если все будет объединено в одну таблицу, это будет очень трудно обслуживать.

(отказ от ответственности: я работал над такой системой с таблицей, содержащей месяцы, дни, типы товаров, true / false(да!), даты праздников и т. д. Это была, по сути, огромная разная сумка для захвата, напоминающая Celestial Emporium of Доброжелательное Знание )

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

Answer 3

то, о чем вы говорите, настолько плохо, что у него есть имя.Это то, что обычно известно как анти-шаблон - шаблон разработки программного обеспечения, которого следует избегать.

имя - One True Lookup Table .

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

таблицы хороши, ссылочная целостность хороша.

Используйте оба при необходимости.

Answer 4

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

cr_status        cr_status_abbr  cr_status
--               -------------------------
Good                       G     Good
Bad                        B     Bad
Unknown (or Unkn)          U     Unknown

, и обе они лучше (IMO), чем таблица, которая реализует ограничение домена, используя целое число в качестве своего первичного ключа.(Поскольку каждая такая таблица требует дополнительного объединения для получения информации, которую могут использовать люди.)