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

Question

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

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

Я изо всех сил, чтобы решить между двумя подходами

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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 

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