Те же поля в большинстве таблиц

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

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

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

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

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

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

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

Однако в конечном итоге 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

Короче говоря, нормализуйте данные, а не структуру базы данных.

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

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

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

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

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

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