I just gotta ask. Imagine you have a table, call it - Company. To me, the table name is implicit in the attribute names. So, to me, when you name an attribute "CompanyXXX" I find this redundant. To me, it should just be "XXX". So, you get
Company.ID
Company.email
as opposed to
Company.CompanyID
Company.CompanyEmail
But DBA folk must not think that way, 'cause it's never named like that - why is that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I talked to some "real" DBA folk about this. One reason is that you can get the various fields without aliasing. This is somewhat weak. The main reason is laziness and readability. (Should that be "The main reasons ARE laziness and readability." When it comes time to join tables, it looks a tad funny to say something like:
Select Company.Name as CompanyName, OtherTable.Name as OtherName
From Company, OtherTable
InnerJoin Company on Company.ID = OtherTable.CompanyID
On the other hand, that is not so silly looking at all. This was one of the questions I had for you guys. If you like the "ID" column, it's an easy switch. If you like the "<i>Entity<i>ID" construct, easy, too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose it doesn't matter to us, since we will be pulling the data into objects with attributes of our own naming. I was more curious than anything. When I get lazy I can copy SQL like:
select * from table a where id = ?
to another SQL statement fofr another table by just pasting it and changing the table name. Same for deletes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just gotta ask. Imagine you have a table, call it - Company. To me, the table name is implicit in the attribute names. So, to me, when you name an attribute "CompanyXXX" I find this redundant. To me, it should just be "XXX". So, you get
Company.ID
Company.email
as opposed to
Company.CompanyID
Company.CompanyEmail
But DBA folk must not think that way, 'cause it's never named like that - why is that?
Hrmm....well, that's not the case at TNOW ;) It is with ID usually but once your past ID -- no buerte.
I talked to some "real" DBA folk about this. One reason is that you can get the various fields without aliasing. This is somewhat weak. The main reason is laziness and readability. (Should that be "The main reasons ARE laziness and readability." When it comes time to join tables, it looks a tad funny to say something like:
Select Company.Name as CompanyName, OtherTable.Name as OtherName
From Company, OtherTable
InnerJoin Company on Company.ID = OtherTable.CompanyID
On the other hand, that is not so silly looking at all. This was one of the questions I had for you guys. If you like the "ID" column, it's an easy switch. If you like the "<i>Entity<i>ID" construct, easy, too.
I suppose it doesn't matter to us, since we will be pulling the data into objects with attributes of our own naming. I was more curious than anything. When I get lazy I can copy SQL like:
select * from table a where id = ?
to another SQL statement fofr another table by just pasting it and changing the table name. Same for deletes.