(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 "in

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