>create a new database and was about to name my primary key field. In the
>past, I've based the name on the table name, ie on table orders, order_id.
>Sometimes that results in some long field names. So, does anyone see a
>downside to naming it a simple "id" or maybe "rowid" or "r_id" or something
>similar?
Other then working on a project with another person no. And even in that
case, familiarity is a learned condition. If you write SQL out in the case
where you always write tablename.table_column then it shouldn't be
problem. But if your standard is to omit tablenames then this will
obviously be a problem; either you will have to start to type your
tablename, reference it, or your SQL statement will not work. I have done
this in the past, and I would say the biggest drawback I faced was when I
came back to some old code and had to re-learn the code. But I wouldn't
say it was more then other stuff.
The other negative thing is that when you do multiple joins and are just
debugging or checking data integrity you will have to include in your SQL code
table1.ID as addressID, table2.ID as phoneID, table3.ID as stateID because
getting back 3 columns with the header ID will not be of any use so there
is more typing for that.
On the flip side, I do see a lot of positives for naming a PK ID or
something standard.
1) You always know what the PK name is.
2) Easier to write code that generates code.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
