Is ID column required in SQL?

Question

Traditionally I have always used an ID column in SQL (mostly mysql and postgresql).

However I am wondering if it is really necessary if the rest of the columns in ea

Answer 1

An ID can be more meaningful, for an example an employee id can represent from which department he is, year of he join and so on. Apart from that RDBMS supports lots operations with ID's.

Answer 2

No, single-attribute keys are not essential and nor are surrogate keys. Keys should have as many attributes as are necessary for data integrity: to ensure that uniqueness is maintained, to represent accurately the universe of discourse and to allow users to identify the data of interest to them. If you have already identified a suitable key and if you don't find any real need to create another one then it would make no sense to add redundant attributes and indexes to your table.

Answer 3

Using IDs to key tables means you can change the content as needed without having to repoint things

Ex. if every row points to a unique user, what would happen if he/she changed his name to let say John Blblblbe which had already been in db? And then again, what would happen if you software wants to pick up John Blblblbe's details, whose details would be picked up? the old John's or the one ho has changed his name? Well if answer for bot questions is 'nothing special gonna happen' then, yep, you don't really need "ID" column :]

Important:

Also, having a numeric ID column with numbers is much more faster when you're looking for an exact row even when the table hasn't got any indexing keys or have more than one unique

Answer 4

Don't confuse the logical model with the implementation.

The logical model shows a candidate key (all columns) which could makes your primary key.

Great. However...

In practice, having a multi column primary key has downsides: it's wide, not good when clustered etc. There is plenty of information out there and in the "related" questions list on the right

So, you'd typically

• add a surrogate key (ID column)
• add a unique constraint to keep the other columns unique
• the ID column will be the clustered key (can be only one per table)
• You can make either key the primary key now

The main exception is link or many-to-many tables that link 2 ID columns: a surrogate isn't needed (unless you have a braindead ORM)

Edit, a link: "What should I choose for my primary key?"

Edit2

For many-many tables: SQL: Do you need an auto-incremental primary key for Many-Many tables?

Answer 5

If you are sure that any other column is going to have unique data for every row and isn't going to have NULL at any time then there is no need of separate ID column to distinguish each row from others, you can make that existing column primary key for your table.

Answer 6

You should have one column in every table that is unique.

EDITED...

This is one of the fundamentals of database table design. It's the row identifier - the identifier identifies which row(s) are being acted upon (updated/deleted etc). Relying on column combinations that are "unique", eg (first_name, last_name, city), as your key can quickly lead to problems when two John Smiths exist, or worse when John Smith moves city and you get a collision.

In most cases, it's best to use a an artificial key that's guaranteed to be unique - like an auto increment integer. That's why they are so popular - they're needed. Commonly, the key column is simply called id, or sometimes <tablename>_id. (I prefer id)

If natural data is available that is unique and present for every row (perhaps retinal scan data for people), you can use that, but all-to-often, such data isn't available for every row.

Ideally, you should have only one unique column. That is, there should only be one key.