Снабжает префиксом каждое имя поля в таблице с сокращенным именем таблицы хорошая практика?

если Вы сделаете это, то Вы закончите тем, что писали запросы как:

SELECT user.user_name, user.user_password, user.user_firstname ...

вместо

SELECT user.name, user.password, user.firstname

так IMO ответ на Ваш вопрос является довольно четким.

Вы не должны больше делать этого, и Вы действительно не должны. Единственным исключением как saua указанный могло быть поле ID для искания ясности соединений.

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

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

Я не сделал бы этого. Если Вы хотите информацию, которые представляют поле в виде таблицы, принадлежит, можно всегда писать запросы как

select user.id, user.name from user where ...

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

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

Помещение префикса на именах столбцов может быть хорошей практикой. Если Вы работаете над формальным (и вероятно крупные) база данных, и Вы обращаете любое внимание на ISO 11179 (особенно понятие имен элемента данных), то хорошо поместить полные три (или четыре) имя части в: Объект - Свойство - Термин Представления. (Четвертая дополнительная часть является спецификатором.), Например, "user_first_name". Тем путем у Вас есть непротиворечивость между Вашим словарем данных и схемой базы данных. Я не сделал бы этого для меньших баз данных по причинам, уже прокомментированным, но в сложной схеме это снижает некоторый риск для ошибки.

Мы также обычно не используем сокращенные префиксы таблицы, и я не был бы совет это также.

Существует однако одна ситуация, где мы делаем: зарезервируйте поля.

 e.g. OH_Reserve_Field_Alpha3 in table ORDER_HEADER

Короткий фон: Наша база данных имеет 250 + таблицы, и мы вставляем большинство из них, резервируют столбцы для использования их для будущих реализаций функции. Как можно предположить, не снабжая префиксом Вас закончил бы тем, что имел 50 Reserve_Field_Alpha3 с полностью другим значением, но тем же именем всюду по Вашему коду. Это уже твердо, как это теперь, но без префиксов это было бы хуже.

Когда я добавляю поле, "порядковое" к таблице, мне нравится добавлять в префиксе, таким образом, я не должен искажать порядковые поля от других таблиц в СОЕДИНЕНИЯХ. Это удобно для СОЕДИНЕНИЙ, иногда... не уверенных, что я видел другие преимущества.

MediaWiki (программное обеспечение Wikipiedia) использует ту конвенцию. Загрузите источник. Они ограничивают себя двумя символьными префиксами.

Я не рекомендую практику все же. Для большинства баз данных не необходимый.

Лично, на 'пользовательской' таблице, мой столбец просто был бы 'идентификатором'.

Но любые внешние столбцы ключа на различных таблицах, указывающих на тот столбец, я назвал бы столбец 'user_id'.

таким образом, Вы могли бы закончить с чем-то вроде этого:

select  *
from    order
        inner join user
            on user.id=order.user_id

По всем приведенным причинам я не думаю, что это - хорошая идея. Кроме того, Вы не снабжаете префиксом все методы в своих классах с именами классов, не так ли? Итак, почему делают это для объектов базы данных?

Вариант префикса просто занимает больше времени для записи и мешает читать sql операторы со многими полями.

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

SELECT user.name, image.name FROM user, image

не очень отличается от

SELECT user_name, image_name FROM user, image

Преимущество havong, никакие неоднозначные поля в Ваших запросах быстро не съедены издержками необходимости ввести имя таблицы каждый раз, Вы используете имя столбца.

Это в порядке к полям имени тот путь (минимально), но для первичного ключа и подписей/имени. Если Вы последовательно называете весь свой первичный ключ как идентификатор и имя, поскольку Имя, создавая запрос ухудшится в лишние псевдонимы:

select i.id as invoice_id

v.id as vendor_id, p.id as product_id, 
v.name as vendor, p.name as product, b.name as branch, c.name as parcel,

i.total_amount,
i.discount,
i.invoice_date

from invoice i
join product p on i.product_id = p.id
join vendor v on i.vendor_id = v.id
join branch b on i.branch_id = b.id
join parcel c on i.parcel_id = c.id

Как присоединяющиеся таблицы и отображение подписи/имени объекта норма, а не исключение, я называю свой первичный ключ в полной форме, и для подписи/поля имени, то же имя как имя таблицы.

create table product
(
product_id uuid not null, -- primary key
product text not null,
bar_code text not null default '',
rfid_code text  not null default '',
current_qty int default 0
);

create table vendor
(
vendor_id uuid not null, -- primary key
vendor text not null,
is_active boolean not null default true
);

create table branch
(
branch_id uuid not null, -- primary key
branch text not null,
sub_branch_of_id uuid,
current_sales money not null default 0,        
);

create table user
(
user_id uuid not null, -- primary key
user text not null,
password text not null default ''
);

Таким образом, Ваш запрос не будет иметь лишних псевдонимов:

select i.invoice_id, p.product_id, v.vendor, p.product, b.branch, c.parcel,

i.total_amount,
i.discount,
i.invoice_date

from invoice i
join product p on o.product_code = p.product_code
join vendor v on o.vendor_code = v.vendor_code
join branch b on o.branch_code = b.branch_code
join parcel c on o.parcel_code = c.parcel_code

Это - потрясающая практика:

1. Вы видите то, что каждое поле означает, по крайней мере, в том, каково домен это. Вы не можете выяснить что amount средства (transactions, incomes) — если они не xac_amount и inc_amount. Большинство инструментальных средств формирования запросов не производит псевдоним наряду с именем поля.
2. Можно использовать псевдонимы таблиц, наверняка. Но SQL не требует их, и согласно закону Murphy's, если он не будет требоваться, то он не будет использоваться. Нет никакого стандарта, таким образом, один разработчик будет использовать x как псевдоним для transaction, другой будет использовать tran и так далее.

На самом деле префиксы являются просто вызванными псевдонимами таблиц, таким образом, можно легко видеть, какое поле принадлежит какой таблица.