Re: Database Design for Shopping Cart

>> I don't quite understand. Whether something is collective or not is
surely determined by the cardinality of the relationship between tables? <<

I am talking about the table names themselves. For example,

employee = bad, unless you only have one of them

employees = better, since it implies more than one of them

Personnel = best, since it gives the role of the set qua set.

>> Just out of interest, what's the reasoning behind not including
things like
"tbl" in object names? <<

A name should tell you what the entity or relationship means, not how it is stored. Also, from the 1970's software engineering work, the prefixes increase errors in maintaining the code.

>> ideally the application should be ony concerned with the external
view that is exposed to it by the RDBMS. Whether it's a view, a procedure or a table should be irrelevent? <<

Bingo! Also, do you care if something is an integer or a character string, if it is used as an identifier or code? The storage (i.e. datatype) will not change in SQL, like it can with OO languages.

We had to use prefixes in early languages that were closer to the machinery -- Variable names that began with "I" thru "N" were integers n FORTRAN; Variable names that began with "$" were strings in BASIC, etc.

>> ... Bshould stored procedures also not contain things like "sp" in
the name to indicate object type? <<

Yes; look for a verb. The other problem is that "sp_" means "system Procedure" so the local database is not searched first for the reference. Received on Mon May 13 2002 - 22:44:16 CEST