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

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

в конечном счете, функции 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

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

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

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

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

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

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

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

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

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

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

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

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

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