How I Write SQL, Part 1: Naming Conventions (2014)
launchbylunch.com
How I Write SQL, Part 1: Naming Conventions (2014)
1–10 of 85 posts
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#2Lot of these is debatable. For example, I have preferred FirstName or even “[First Name]” instead of first_name in sql because lot of tooling uses these names to generate UX. Similarly using Person.PersonID instead of Person.ID gives consistency in diagrams and foreign key naming. I have used both approaches with its own pro and cons.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#3You should follow the conventions that make life easier in the rest of your tooling.
The fact is, you're probably going to be issuing more SQL via abstractions like ORMs or querying libraries than raw SQL. If you need to work against the grain of those libraries to map your model, what upside are you getting?
If most of your data is queried via ActiveRecord, for example, you should use plural table names.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#4How come I have never in a multi decade career come across "i18n".
I though the canonical way of doing this was to write KEYWORDS in caps and use camel case for Variables.
Also never really brought into adding the type as part of a name - your type is already defined in your schema.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#5You should follow the conventions that make life easier in the rest of your tooling. The fact is, you're probably going to be issuing more SQL via abstractions like ORMs or querying libraries than raw SQL. If you need to work against the grain of those libraries to map your model, what upside are you getting? If most of your data is queried via ActiveRecord, for example, you should use plural table names.
Don't use an ORM is the answer just put in the effort to lean SQL
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#6Lot of these is debatable. For example, I have preferred FirstName or even “[First Name]” instead of first_name in sql because lot of tooling uses these names to generate UX. Similarly using Person.PersonID instead of Person.ID gives consistency in diagrams and foreign key naming. I have used both approaches with its own pro and cons.
> For example, I have preferred FirstName or even “[First Name]” instead of first_name in sql
Do not do this in Postgres, it will be a pain in the ass since you will have to use quotes around everything.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#7I personally prefer person_id to be the primary key name (instead of id) in both the person table and any table which has it as a foreign key. One reason is for join syntax:
select * from person join team_member using (person_id)
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#8You should follow the conventions that make life easier in the rest of your tooling. The fact is, you're probably going to be issuing more SQL via abstractions like ORMs or querying libraries than raw SQL. If you need to work against the grain of those libraries to map your model, what upside are you getting? If most of your data is queried via ActiveRecord, for example, you should use plural table names.
Don't use an ORM is the answer just put in the effort to lean SQL
That is a weird middlebrow dismissal of a response with essentially no value to anybody.
Use an ORM when appropriate; when using one, follow its conventions. Don't use an ORM if it's not appropriate. This is much better advice.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#9You should follow the conventions that make life easier in the rest of your tooling. The fact is, you're probably going to be issuing more SQL via abstractions like ORMs or querying libraries than raw SQL. If you need to work against the grain of those libraries to map your model, what upside are you getting? If most of your data is queried via ActiveRecord, for example, you should use plural table names.
It is true that most of my SQL goes through ORMs. However my most complicated SQL is always constructed by hand. Furthermore note the point about how often applications get rewritten against the same database. You should not assume that future code will use the same ORM that you are using now.
Re: How I Write SQL, Part 1: Naming Conventions (2014)
#10How come I have never in a multi decade career come across "i18n". I though the canonical way of doing this was to write KEYWORDS in caps and use camel case for Variables. Also never really brought into adding the type as part of a name - your type is already defined in your schema.
Really? I have. In some circles (e.g., the IETF), i18n is an ancient acronym. People who've worked on operating systems (e.g., OS X, Solaris, RHEL, whatever) have to deal with L10N (localization). G11N (globalization) is I18N + L10N.
And then there's a11y: accessibility. This is all about making user interfaces accessible for people with low or no vision, low or no hearing, difficulty typing, and so on.
There are generally applicable laws requiring G11N and A11Y, and these fall heavily on OS vendors, which is why people who've worked on OSes tend to know these acronyms.
I18N -> dealing with Unicode in general, codeset conversions, font issues, ...
L10N -> dealing with translating system/application messages to the users' preferred languages (and how to even know they preferences) (think locales)
G11N -> I18N and L10N.
Localization is damned difficult. There's all sort of little bothersome things, like how to format numbers (which varies quite a lot) and dates (can't we all just use ISO-8601?!). And translating printf-like format strings is often non-trivial, especially when the coder doesn't stop to think about just how hard they might be to a translator as they write their code.