Re: Database Design for Shopping Cart
Date: 13 May 2002 13:44:16 -0700
Message-ID: <c0d87ec0.0205131244.7cdea235_at_posting.google.com>
>> I don't quite understand. Whether something is collective or not is
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.
surely determined by the cardinality of the relationship between
tables? <<
>> Just out of interest, what's the reasoning behind not including
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.
things like
"tbl" in object names? <<
>> 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