3 ms·

1) Fair enough, up to the designer's taste 2) Do you mean "not real good with case-sensitivity" or just "case insensitive"? If the latter database still preser

1) Fair enough, up to the designer's taste 2) Do you mean "not real good with case-sensitivity" or just "case insensitive"? If the latter database still preserves the case, then the underscore on an all-caps name is even uglier. 3) driversLicenses.id is not the same thing as vehicles.id. The point is to name the column what it is so the meaning is preserved everywhere. If you don't use aliases then you can't distinguish them in the result set. If you do use aliases then an app that reads and updates has to now remember that the alias isn't its real name. 4) I haven't noticed the mental cache problem myself, sorry. But a table called "vehicle" isn't a vehicle. I don't believe the issues with "person" vs. "persons" or even "sheep" vs. "sheeps" is worth the mental cache problem of remembering if you're dealing with a row or the entire table in the context of the application. 5) Conceded 6) The point of the article is about using naming to improve clarity, including where metadata like domains and check constraints aren't visible, such as printouts. The postfixes don't even encode type, but information about how the value is defined. A books table with a "ddc" column isn't hurt by adding "_class", but you're also communicating that the value comes from an international standard classification system (Dewey Decimal). I don't know of a database system that can encode this meaning in types, domains or check constraints. On critique of _skidmarks and StudlyCaps, I guess I should have emphasized the concept of coding to what the toolchain and environment's conventions suggests, such as putting "When In Rome, Always Do As Romans Do" in boldcase at the top of the sidebar. Like I had.

kevbin 17y ago
(1) is a ticky-tack foul, just pointed it out because "Choosing the right name is everything" is pretty hyperbolic and I was being hyperbolic, too, with the "insane" bit. (2) I'm biased toward _-naming in general, I think it's less ugly than camelCase. But my point (2) is just from experience: developing on MySQL on a Mac (case-insensitive filesystem, case-insensitive naming by default) and Linux (case-sensitive) and porting from MySQL to Oracle. Under-barring is least-common-denominator approach that's likely to save some time and frustration. (3) You'll have name-collided columns in the result set regardless of what they represent. PERSON and PET may both have a nickname column, when you join pets and their owners, you're going to need to qualify or alias nickname. (4) You're right, a table called "vehicle" isn't a vehicle. But I don't think of it as a list of vehicles either, I think of the table definition as being SQL approximation of the definition of "vehicle-ness", each tuple is a vehicle and a select from the table will get you a list of vehicles, but the definition is "what it means to be a vehicle" approximated in SQL as CREATE TABLE VEHICLE (...)". This helps to maintain the "relational mindset" and avoid slipping into the VisiCalc mindset when dealing with relationships between relations. (6) You're right on about the importance of clarity, but I think clarity improves with concision. Qualified names are clearer in this respect than names overloaded with metadata. I realize that a lot of databases don't have good support for defining types and domains (postgresql seems to, though), when there are ways to encode the metadata you want without polluting the name space use them. You're right on about the prominence of "When In Rome…", sorry, it didn't even reach my consciousness.
adelle 17y ago
4) I think of the table name as describing the tuples it contains, not the table itself. SQL reads better that way.

kevbin 17y ago

(1) is a ticky-tack foul, just pointed it out because "Choosing the right name is everything" is pretty hyperbolic and I was being hyperbolic, too, with the "insane" bit. (2) I'm biased toward _-naming in general, I think it's less ugly than camelCase. But my point (2) is just from experience: developing on MySQL on a Mac (case-insensitive filesystem, case-insensitive naming by default) and Linux (case-sensitive) and porting from MySQL to Oracle. Under-barring is least-common-denominator approach that's likely to save some time and frustration. (3) You'll have name-collided columns in the result set regardless of what they represent. PERSON and PET may both have a nickname column, when you join pets and their owners, you're going to need to qualify or alias nickname. (4) You're right, a table called "vehicle" isn't a vehicle. But I don't think of it as a list of vehicles either, I think of the table definition as being SQL approximation of the definition of "vehicle-ness", each tuple is a vehicle and a select from the table will get you a list of vehicles, but the definition is "what it means to be a vehicle" approximated in SQL as CREATE TABLE VEHICLE (...)". This helps to maintain the "relational mindset" and avoid slipping into the VisiCalc mindset when dealing with relationships between relations. (6) You're right on about the importance of clarity, but I think clarity improves with concision. Qualified names are clearer in this respect than names overloaded with metadata. I realize that a lot of databases don't have good support for defining types and domains (postgresql seems to, though), when there are ways to encode the metadata you want without polluting the name space use them. You're right on about the prominence of "When In Rome…", sorry, it didn't even reach my consciousness.

adelle 17y ago

4) I think of the table name as describing the tuples it contains, not the table itself. SQL reads better that way.