SQL style guide – a consistent code guide ensuring legible and maintainable code | Hacker News Reader

SQL style guide – a consistent code guide ensuring legible and maintainable code

sqlstyle.guide

16 pointsTreffynnon10 comments

"Use a collective name or, less ideally, a plural form. For example (in order of preference) staff and employees."

I hope Simon Holywell has never had to model a zoo in SQL. "Where are the rattlesnakes Simon - are they in the rhumba, crash or knot table?" [1]

[1] http://blog.writeathome.com/index.php/2013/03/improved-anima...

Amusing example however as you'll know following a style guide doesn't preclude one from using their own intelligence to choose sensible options rather than delving into the absurd.

What's the stance on using tabs to keep the stuff after keywords lined up? Whacking space a bunch of times to keep an OR lined in a WHERE clause is incredibly annoying. Why not just go WHERE\tcol1 = 3\n\t\tORcol2=6

    select	*
    from	asdf
    where	col1 = 5
    	or	col2 = 6

I'll concede that the river is less pretty, but it's substantially easier to type, and SQL keywords are remarkably conducive to being tabbed around.

EDIT: Perhaps hilariously, by preceding the code with two spaces, the stuff got out of alignment. I'm adding another two padding spaces to start. (I usually use a 4 space tab, but I can see how the river becomes a bit wide on 8.)

"Use a collective name or, less ideally, a plural form. For example (in order of preference) staff and employees."

This goes contrary to what I was taught : use singular form. When I model my databases I think in those terms : employee works for 1 to n company, company has 0 to n employee. Since it's a "many to many" relationship you need a third table (entity really) which you could call "working_with". The columns are id_employee and id_company.

This is the basis of the Merise method, but I don't think it's available in English. It makes modeling databases really easy.

I also use singular for every table and column name. It just makes everything simpler. If I had table of scissors, it would be called `scissor`.

I would suggest a different approach: Prefer either the plural or singular form, depending on which your ORM prefers. It may not be pretty from a purely stylistic perspective, but the collective forms have a few specific problems:

- mapping is not intuitive for non-native English speakers (flora, really?!)

- manual table mapping needed for ORM systems

I'd prefer the singular, but ActiveRecord uses the plural, and I'd rather go along with the default, rather than fight and create friction for my team.

EDIT: looking closer, the style guide is great, but the naming conventions are atrocious. I'm reminded of what my Intro to CS TA told us: naming stuff is hard, so try to explain your code. If you have to explain what something is, the explanation should be the name (within reason)

When modelling data it should be the primary concern and not an ORM. Different applications will need access to the same information. ORMs are application specific and therefore should not determine how data is structured.

As for the non-English speakers finding the collective difficult; I can see that. I have not specifically considered their needs whilst compiling the guide. In the case of `flora` I am guessing you're thinking `plant`?

I suppose if you need a style guide for SQL, then you're likely in the business of building databases to be accessed by multiple applications. However, be aware that the majority of applications are initially developed using a database as a data store, alongside opinionated ORM systems that will prefer a specific naming convention (such as plural forms).

Speaking from experience, you can't even expect native speakers to know all the collective forms. Worse, in some cases the collective form may cause confusion if the collective is the singular of a different table (players in a team, teams in a league, doing a fantasy football league app).

Using the plural, your schema would be player -> team -> league. Using your system, it would be team -> league -> sport. Good luck explaining that to a new hire.

No, actually the collective of player isn't team in this case.

Not all players will be on the same team, but they still participate in the league so I disagree with this example terminology shift.

You would end up with a slightly more generalised naming like this in my opinion:

- athletes - teams - leagues

In this particular case there are no suitable collective terms.

This is an interesting idea. I will give it some thought as others have also suggested similar. Perhaps the guide could be relaxed a little to allow singular names.

Someone mentioned that tables can be considered like types - another interesting thought - in which case singular makes sense.

On the other hand it is a collection of something and therefore the collective term applies equally well.

Reply on news.ycombinator.com