Naming primary keys "id" vs "something_id" in SQL

Question

I am wondering what is best suited for naming primary / unique keys in a database with many tables. If you always just call the primary key of each table id or it is normal not to have an id field in each table and just call each of them something1_id , something2_id , etc.

Answer 1

No matter what you do, choose one or the other and stick to this standard. For each, there are pros and cons.

I prefer SomethingID , but other people prefer just ID . The system I work on has more than a thousand tables, and PC and FK have the same name, which simplifies the work.

Answer 2

This is a personal preference. In the end, it does not matter. I personally prefer to use only Id , as I find that I am referencing the Customer field (say Customer table and Id ) to be bulky, where Customer.Id seems to make more sense.

Answer 3

This is a matter of preference; however, there is an advantage to using (something) an identifier in that the column names become less ambiguous when you perform joins between tables.

Answer 4

id is just a convenient convention - you can call a field anything you want while you declare it as a key field.

An identifier prefix with an appropriate context can be useful when it comes to reading and writing code, and especially improves readability when combining data from multiple tables and foreign keys.

Answer 5

There are bunches of articles there, go check it out ...

dB naming conventions

Answer 6

I suggest you use an abbreviation for long names and use (something) Id (e.g. user_id ) for regular tables. Therefore, for the customer_company_relation_metadata table, use ccm_id . But his fine in using id as well