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

Question

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

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

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

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

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

• Как указано выше, но вместо внешнего ключа используйте атрибуты.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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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