>>>> 2011/08/08 00:13 -0600, Mike Diehl >>>>
Well, I can see this being useful in assembly language, or strongly-typed,
non-OO languages. But I was asking specifically about SQL!
....
We know from context that customers is a table and it makes no sense at all to prefix a
type to it in order to make the obvious more clear.
<<<<<<<<
I suspect it makes the most sense in weakly typed languages, and, therefore, quite useless
in table names. TAble names are not found in the same context as field names, and the same
name may be used for both table and field in the table--field names, on the other hand,
....
In the PL1 (and scripting-language) tradition, although in the table definition there is
fairly narrow description of the type, much implicit conversion is allowed. It is also in
the PL1 tradition that operators yield values of some vague type ('+' yields number, '||'
yields character: no general operator overloading), but with all the conversion it seldom
is clear to the user what a generated field s exact type is: even which numeric type, even
which character type, with what length. Then there is room for tacking type descriptions
onto names.
>>>> 2011/08/08 00:13 -0600, Mike Diehl >>>>
My personal convention is that table names are plural. Foreign indexes have
the table name as a prefix.
<<<<<<<<
To me a table is like an array, and therefore I make it singular: "invoice", say, is an
array of invoices, and "invoice [ 5 ]" is invoice 5. My plurals are for counts of things;
if "invoice" is a table, then
select count(*) as invoices from invoice
