Re: identity columns

> I noticed that you said "representation of its instances" and not
> "set" or "class" and that might be important. OO people think of
> instances rather than sets. I would say that a forest contains trees;
> you would say that there is no such construct as a forest, but only
> instances of trees. This goes back to the concepts that Cantor
> introduced with set theory.

I've given this considerable thought - because just about every database I've ever worked with has used singular names. I can see how you could argue for singular or plural names. Since I recently became a technical lead - I've had to enforce some naming conventions

Here's why I go for singular:
When looking at table "Order" I see columns OrderId, Quantity, Price, etc. If I make the table plural - shouldn't everything be plural? I have a number of naming rules in place so my group doesn't go nuts when writing database code - one of them being that if we make a synthetic key for a table - it's always "TableNameId" and OrdersId seems kinda awkward - but I know you hate those synthetic keys anyway <s>
So how about another table called "ApprovalStatus" - I think of an orders in one of many states which are defined in that table. Should it be "ApprovalStati"
That may make more sense for the ApprovalStatus table but Orders would have a foreign key called "ApprovalStatiCode" - but there is only 1 ApprovalStatus
associated with each Order - so ApprovalStateCode seems more appropriate.

However - I can see a big argument for your way. On my computer I have a "Projects" folder - in fact - there are plenty of things
that are sets and the name derives from that fact. But then there are things like "The Rule Book" - which is really "A Set of Rules" The more I thought about this - the more I really see it as an issue of how you view a set - is it a "set of things" or "a set of that thing of a certain type"

The funny thing about this thread - however - is how somebody brought up the issue of books - alluding to how we should follow something because it's in a book. One common coding convention in SQL books is to use upper case for all sql keywords. The thing I found in project maintenance
is that I don't care so much about the sql as I do about everything else in the proc, view, query or whatever it is I'm looking at. Case in point:

case1: SELECT OrderId, Quantity FROM Orders -or-
case2: select OrderId, Quantity from Orders

I've been doing a little research into graphic design theory and it's carried over into other areas of my development life. Having something in UPPER CASE draws attention to it - is that where you want the attention drawn? I'm pretty good with the sql syntax at this point so I'd rather have attention drawn to the other parts of the sql code. Received on Sun Feb 03 2002 - 06:05:06 CET