Одинаковые поля в большинстве таблиц

Question

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

Эти поля всегда имеют одинаковые функциональные возможности конечного пользователя для маркировки, отображения, поиска, фильтрации и т. Д. Они не являются частью ограничения внешнего ключа. Как это должно быть смоделировано?

Я могу представить следующие варианты:

• Каждая таблица получает все эти атрибуты. В таком случае, как бы вы назвали их? То же самое в каждой таблице или с префиксом имени таблицы (например, usrName, prodName)

• Переместите их в таблицу Attributes, добавьте внешний ключ к «основным» таблицам, ссылаясь на Attributes.PK

• Как указано выше, но вместо внешнего ключа используйте Attributes.PK в качестве PK в соответствующей базовой таблице.

Answer 1

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

в конечном счете, однако, user.name и user.description являются функциональными возможностями, отличными от product.name и product.description, и должны рассматриваться как таковые. для status это зависит от того, что вы подразумеваете под этим. status является просто индикатором активности продукта / записи пользователя или нет? если это так, то имеет смысл разделить это на другую таблицу.

используя предоставленную вами информацию, если «активно / просрочено / удалено» является просто указанием состояния в базе данных, то я бы определенно согласился со структурой таблицы следующим образом:

users            products         status
  id               id               id
  name             name             name
  description      description
  status_id        status_id

однако, если бы status можно было предположительно изменить для представления чего-то семантически отличного (т. Е. Для пользователей, возможно, "активных / отставных / запущенных"), я бы предложил разделить это до будущего подтверждения дизайна:

user_status     product_status
  id              id
  name            name

Короче,

, нормализуйте ваши данные, а не дизайн базы данных.

Answer 2

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

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

Answer 3

Я всегда давал каждой таблице трехбуквенный код, который я затем использую во всех именах полей. Таким образом, в таблице продуктов у меня есть prdname, prddescription, prdstatus, а в файле vendor у меня есть venname, vendescription, venstatus. Когда вещи объединяются, нет необходимости беспокоиться о полях с одинаковыми именами.

Конечно, во всех таблицах есть поле с именем plain old id , а в таблице продукта будет поле с именем venid, которое ссылается на поле id в таблице vendor. В этом случае я не ставлю префикс prd, потому что venid имеет смысл и недвусмысленен.

Answer 4

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

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

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

Что касается имен столбцов, нет необходимости или целесообразно ставить префиксы для имен столбцов. Если вы когда-либо выполняете объединение, в результате которого столбцы с одинаковыми именами появляются в двух таблицах, используйте псевдонимы, чтобы различать их.

Answer 5

Нормализация часто является наилучшей практикой в ​​любой реляционной базе данных (в пределах разумного).

Если у вас есть такие поля, как состояние (имеется в виду состояние внутри страны), то ссылочная таблица, такая как «Состояние» с (id, short_name, long_name и т. Д.), Может быть подходящим вариантом, тогда каждая запись, ссылающаяся для состояния нужен только столбец state_id, который, как вы упоминали, является ссылкой на запись в таблице состояний.

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

Надеюсь, это поможет.