Те же поля в большинстве таблиц
Вы можете получить местоположение модели пользователя из config/auth.php . Однако, если приложение использует другой метод аутентификации, это не сработает.
Я думаю, что ваш лучший вариант - сделать путь к классу к модели User настраиваемым .
5 ответов
это кажется, что Вы могли бы брать идею нормализации немного слишком далеко. помните, это - идея, что Вы уменьшаете дублирование в своих данных. Ваш пример, кажется, указывает, что Вы волнуетесь по поводу "дублирования" в метаинформации Вашего проектирования баз данных.
в конечном счете, хотя, 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
Нормализация часто является лучшей практикой в любой реляционной базе данных (в причине).
Если у Вас есть поля как состояние (значение состояния в стране), то ссылочная таблица как "состояние" с (идентификатор, short_name, long_name и т.д....) могла бы быть способом пойти, то каждой записи, которая ссылается на состояние только, нужен state_id столбец, который, как Вы действительно упоминали, является ссылкой на запись в таблице State.
Однако в некоторых случаях нормализация всех данных не обязательно требуется, поскольку это просто усложняет вещи, но должно быть очевидно, где сделать это и где не сделать это.
Надеюсь, это поможет.
Я дал бы каждой таблице его собственный набор столбцов, даже если они имеют те же имена и логически подобны.
Если когда-нибудь необходимо изменять одну из таблиц путем добавления или удаления некоторых из этих столбцов или изменения их типа данных, то можно сделать это только в таблице, где он принадлежит, вместо того, чтобы выяснить, как усложнить общую таблицу атрибутов.
Предоставление каждого табличного элемента управления его собственных атрибутов продвигает Сцепление, которое является хорошей вещью. Это также избегает Вашего вопроса, о котором направлении идут внешние ключи.
Что касается именования столбца, это не необходимо или желательно поместить префиксы на имена столбцов. Если Вы когда-нибудь делаете соединение, которое приводит к столбцам того же имени, прибывающего из двух таблиц, используйте псевдонимы для различения их.
Я всегда давал каждой таблице трехбуквенный код, который затем использую во всех именах полей. Таким образом, в таблице продуктов у меня есть prdname, prddescription, prdstatus, а в файле vendor - venname, vendescription, venstatus. Когда элементы объединяются, нет необходимости беспокоиться о полях с одинаковыми именами.
Конечно, все таблицы имеют поле с именем plain old id , а в таблице продуктов будет поле с именем venid, которое ссылается на в поле id в таблице vendor. В данном случае я не добавляю к нему префикс prd, потому что venid имеет смысл и однозначен.