Do you prefix each field in a table with abbreviated table name?
Example:
Table: User
Fields:
user_id
user_name
user_password
Or d
It's ok to name fields that way(minimally), but for primary key and captions/name. If you consistently name all your primary key as ID, and name as Name, constructing query will degenerate into superfluous aliases:
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
As joining tables and displaying the entity's caption/name is the norm rather than exception, I name my primary key in full form, and for caption/name field, the same name as table name.
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 ''
);
So your query won't have superfluous aliases:
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
I wouldn't do it. If you want the information which table a field belongs to, you can always write your queries as
select user.id, user.name from user where ...
But imagine you decide for whatever reason to rename one of your tables (maybe from 'user' to 'customer'). You would have to rename all fields as well, to remain consistent.
My opinion: There is no good reason why you should do it, and several good reasons not to do it.
Putting the prefix on column names can be a good practice. If you're working on a formal (and probably large) database and you're paying any attention to ISO 11179 (particularly the concept of data element names), then it's good to put the full three (or four) part name in: Object - Property - Representation Term. (The fourth optional part is a qualifier.) For example, "user_first_name". That way you have consistency between your data dictionary and the database schema. I wouldn't do this for smaller databases for the reasons already commented on, but in a complex schema this reduces some risk for error.
You do not need to do it anymore, and you really should not. The only exception as saua pointed out could be the ID field for the seek of clarity of joins.
The concept of prefixing field names with the table name comes from the old time of legacy systems when each field across the whole database needed to be unique.
So unless you are dealing with legacy systems which require that each field across the whole database has unique name; do not do it.
I'd recommend sticking with table aliases, like:
SELECT
user.id,
user.email,
user.firstname,
user.secondname,
avatar.filename
FROM
pain_in_the_butt_table_name user
LEFT JOIN
table_with_the_avatars avatar
ON avatar.user_id = user.id
The advantages:
maintaining an easily comprehendable list of fields you select, and which tables you take them from
avoid typing long or hard to comprehend table names and replace them with a short and understandable name (which you should have done when creating the table)
LEFT JOIN table_with_the_avatars.user_id ON user.user_id = table_with_the_avatars.avatars_user_i
The prefix variant just takes longer to write and makes it harder to read sql statements with many fields.
Even when you are selecting from several tables, this gives you only the benefit of not having to prefix ambiguous fields with the table name. But
SELECT user.name, image.name FROM user, image
is not very different from
SELECT user_name, image_name FROM user, image
The benefit of havong no ambiguous fields in your queries is quickly eaten up by the overhead of having to type the table name each time you are using a column name.