Main Page | Report this Page
Computers Forum Index  »  Computer - Databases  »  should entities in a database be named using singular...
Page 1 of 1    

should entities in a database be named using singular...

Author Message
metaperl...
Posted: Fri Aug 14, 2009 12:37 pm
Guest
Is there a good *reason* why entities in a database should be named
using singular instead of plural?

I can certainly see why columns should be singular, but I'm not so
sure about entities.

For example, in this schema:
http://github.com/metaperl/DBIx--Shootout/blob/555a5dc775690fd55a0b9d6237d2f3e2ec8905b4/lib/DBIx/Shootout/GMAX/schema.pdf

we see that the database designer chose plural names for entities and
singular names for columns.


A similar issue exists in programming languages. You dont have an
array of integers. You have an array in which each element is an
integer.

I guess it all starts with "wrong english" - a bucket of apples is
really a bucket in which each element is an apple.
 
Terrence Brannon...
Posted: Fri Aug 14, 2009 12:48 pm
Guest
On Aug 14, 8:37 am, metaperl <metap... at (no spam) gmail.com> wrote:
Quote:
Is there a good *reason* why entities in a database should be named
using singular instead of plural?

Microsoft seems to think there is not: http://msdn.microsoft.com/en-us/library/dd129510(VS.85).aspx

"""
Tables contain collections of entities and should have a plural name
to reflect this. For example, a table of addresses should be named
AddressesTable rather than AddressTable.
"""
 
Terrence Brannon...
Posted: Fri Aug 14, 2009 3:44 pm
Guest
On Aug 14, 8:37 am, metaperl <metap... at (no spam) gmail.com> wrote:
Quote:
Is there a good *reason* why entities in a database should be named
using singular instead of plural?

I can certainly see why columns should be singular, but I'm not so
sure about entities.

I think I see the reasoning for singular entity names... the entity is
the ROW, not the TABLE of rows...
 
Walter Mitty...
Posted: Fri Aug 14, 2009 6:37 pm
Guest
"metaperl" <metaperl at (no spam) gmail.com> wrote in message
news:7bc8bd4c-18e7-47c8-ab87-03dd7db14b9b at (no spam) c29g2000yqd.googlegroups.com...
Quote:
Is there a good *reason* why entities in a database should be named
using singular instead of plural?


It's subjective. I use plural names for tables, most of the time. There
are other people who insist on singular table names.


About the only thing I'm going to support is consistency. Once a choice has
been made about naming conventions for a given project, people who name
things should adhere to the convention. That makes for easier reading later
on.
 
Walter Mitty...
Posted: Sat Aug 15, 2009 12:51 am
Guest
"Terrence Brannon" <metaperl at (no spam) gmail.com> wrote in message
news:bb973e60-0d5a-46b3-ab5b-101c6b710966 at (no spam) c34g2000yqi.googlegroups.com...
On Aug 14, 8:37 am, metaperl <metap... at (no spam) gmail.com> wrote:
Quote:
Is there a good *reason* why entities in a database should be named
using singular instead of plural?

I can certainly see why columns should be singular, but I'm not so
sure about entities.

I think I see the reasoning for singular entity names... the entity is
the ROW, not the TABLE of rows...

The entity instance is the row. The entity type is the table.
 
dami...
Posted: Mon Aug 17, 2009 8:53 am
Guest
On 14 août, 22:51, "Walter Mitty" <wami... at (no spam) verizon.net> wrote:
Quote:
"Terrence Brannon" <metap... at (no spam) gmail.com> wrote in message

news:bb973e60-0d5a-46b3-ab5b-101c6b710966 at (no spam) c34g2000yqi.googlegroups.com...
On Aug 14, 8:37 am, metaperl <metap... at (no spam) gmail.com> wrote:

Is there a good *reason* why entities in a database should be named
using singular instead of plural?

I can certainly see why columns should be singular, but I'm not so
sure about entities.

I think I see the reasoning for singular entity names... the entity is
the ROW, not the TABLE of rows...

The entity instance is the row.  The entity type is the table.

In "Data Modeling Essentials" (Simsion&Witt, Elsevier, §10.18.1
"Naming Conventions") : "Entity class names must be singular and
noncollective (e.g. "Employee" or "Employee Transaction", but not
"Employees", "Employee Table", nor "Employee History").

But not everybody agrees --- google for "data modeling table name
singular", there are many links. See for example
http://discuss.joelonsoftware.com/default.asp?joel.3.685443.15
and http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=5904
 
--CELKO--...
Posted: Tue Aug 18, 2009 12:51 pm
Guest
Quote:
we see that the database designer chose plural names for entities and singular names for columns.

That is straight out of ISO-11179. The rules are based on the
principle that you name a data element for WHAT it is by its nature,
so most things are scalars and they are singular. If it is a plural
or collective thing like a table, then it gets a collective or plural
name.

Tables are used as sets, not one at a time like records in a file.

Employee = Bad
Employees = Better
Personnel = Best

I have a few chapters on this in SQL PROGRAMMING STYLE, if you want
the details.
 
Lennart...
Posted: Wed Aug 19, 2009 11:03 am
Guest
On 14 Aug, 14:48, Terrence Brannon <metap... at (no spam) gmail.com> wrote:
[...]
Quote:

Microsoft seems to think there is not:http://msdn.microsoft.com/en-us/library/dd129510(VS.85).aspx


A page full of ... surprises

* Append the Word “Table” to the End of Table Names
* Create a Primary Key Named Id

perhaps there is more, I did not read any further ...

/Lennart
 
--CELKO--...
Posted: Wed Aug 19, 2009 6:44 pm
Guest
The paper also states that the surrogate key is created and maintained
by the system, not the user nor is it ever seen by the user. Think of
idexing, perfect hashing, etc. as ways to locate physical data.
Unfortunately, auto-incremenation in many SQLs is not a surrogate key
at all -- it is an exposed phsyical locator (physical row number,
record count or whatever).
 
--CELKO--...
Posted: Fri Aug 21, 2009 3:03 pm
Guest
Quote:
I think the comments reflects Codd's evolving development of the relational model. So I do not think he really advocated use of ID.

You cabn see a lot of Codd's changes over time. PRIMARY KEY was based
on the keys needed for a tape file merge or other sequential file to
work; later, he realizes that "no key is more equal" than others, to
make fun of Orwell. In Relational Model #2, he has two kinds of
NULLs. Etc. He became more abstract over time, as he realized the
assumptions that we were carrying into RDBMS thinking.
 
 
Page 1 of 1    
All times are GMT
The time now is Thu Dec 03, 2009 6:23 am