Re: Database Design for Shopping Cart

From: Bob Hall <bob_at_sten.alder.net>
Date: 13 May 2002 23:20:48 GMT
Message-ID: <slrnae0eur.mu.bob@sten.alder.net>

In article <c0d87ec0.0205131244.7cdea235_at_posting.google.com>, --CELKO-- wrote:

>>> 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.

Personnel may include both employees and contractors, so if table contains members of the class of people who are employees, I would use Employees. It conveys more information.  

>>> 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.

This is being posted to the Access newsgroup. My experience in working with Access is that the opposite is true. Object prefixes specify whether the object is a table or a query, which have different properties. The result is fewer errors. Some subset of Access programmers seem to agree, because the standard naming conventions for VBA include specifications for tables and queries, and these are among the most common prefixes used.  

Bob Hall

-- 
Access Hamsters: Free tools for users, DBAs, and developers.
http://users.starpower.net/rjhalljr   Click on Downloads.

Received on Mon May 13 2002 - 18:20:48 CDT