Algumas semanas atrás, eu perguntei no Twitter sobre convenções de nomenclatura do SQL Schema para profissionais DBA. (Eu estou sempre interessado nas práticas gerais de profissões afins; quando eu posso, tento fazer meu trabalho compatível com os deles, o quanto possível.)

Recebi algumas respostas, representando DBAs de MySQL, PostgreSQL e DB2, mas não tantas que fossem suficientes para uma amostra estatisticamente útil. Mesmo assim, eu vou apresentar as respostas aqui, anonimamente, porque elas me conduziram a um trabalho que eu não tinha considerado anteriormente.

Minhas perguntas foram:

1. Para nomes de tabela, você prefere plural (posts), singular (post) ou algo diferente?
2. Para nomes de coluna de chave primária, você prefere plural (posts_id), singular (post_id) simplesmente id ou outra coisa?
3. Como você nomeia tabelas de associação muitos-para-muitos? Por exemplo, se muitos posts dizem respeito a muitas tags, você prefere combinar os nomes de tabela no plural ou singular? Se assim for, você os separa com um underscore? Os exemplos seriam posts_tags para o plural, e post_tag para singular. Ou você prefere outra abordagem?

As respostas seguem aqui:

Nomes de tabela

• “Tabelas e colunas são no singular, então crie a tabela item, account e não items, accounts“.
• “Mantenha nomes no singular. A razão por trás disso é que foi fácil para fazer referência ao nome da coluna com o nome tabela. Exemplo: “user”.first_name. O maior desafio em usar o singular é que a maioria dos nomes de tabela populares são considerados palavras-chave para os bancos de dados. Alguns dos exemplos: user, order, name, type etc”.
• “Os nomes das tabelas devem ser no plural. É assim que eu aprendi, e parece fazer sentido que um nome para um conjunto de linhas deva ser plural”.
• “Eu prefiro nomes de tabela no plural”.
• “Plural – porque é um conjunto de coisas”.

Nomes de chave primária

• “Cada tabela deve ter um id de chave primária (substituto) usando uma sequência (identidade é ok às vezes)”.
• “Eu prefiro nomes singulares para coluna sem qualquer prefixo ou sufixo”.
• “Eu teria dito post_id, mas durante os últimos anos, tenho mudado para apenas id.
• “Eu prefiro sempre chave primária id.
• “Singular. Por exemplo, UserID“.

Nomes de tabelas de associação

• “Se eu seguir os nomes de tabelas no singular, eu uso post_tag_mapping. Eu gosto de usar o sufixo _mapping para identificar explicitamente tais tabelas”.
• “Usamos plural_plural“.
• “Eu prefiro tabelas de mapeamento singulares”.
• “Eu os combino, como SingularPlural e tem, geralmente, a entidade dominante primeiro, já que ela é dona de coisas na segunda entidade. Ex: PostTags, UserRoles ou StudentTests“.

O que isso nos diz?

Não muito, ao que parece. Poderíamos dizer “não há nenhuma prática geralmente aceita”, mas com apenas 5 respondentes isso não é uma conclusão confiável.

Tendo dito isso, um entrevistado resumiu o que parecia ser um sentimento comum desta forma: “A maioria das pessoas provavelmente vai concordar que é sobre um acordo em um padrão, e em seguida, ser coerente com ele”. Eu acho que é frequentemente o caso com os padrões.

Outro entrevistado observou: “Em um tempo muito, muito distante, você teve DBAs de produção, e os de desenvolvimento, que poderiam fazer a modelagem de dados. Mas hoje existem apenas DBAs de produção, e nós sempre herdamos projetos”. Isso certamente se enquadra na minha própria experiência. DBAs profissionais são geralmente contratados mais tarde, com o amadurecimento do negócio, e eles estão presos com as decisões que o profissional não-DBA fez antes da sua chegada. E esses esquemas pré-existentes os deixam de mãos atadas.

What Would Joe Celko Do (O que Joe Celko Faria)?

No entanto, mais de um entrevistado se referiu ao Estilo de programação SQL, de Joe Celko, que eu imediatamente procurei e fui ler.

Eu achei que as recomendações de Celko fizeram muito sentido. No começo, pensei que eu teria que copiar as seções relevantes aqui, mas Simon Holywell já fez isso em seu Guia de Estilo SQL.

As respostas de Celko para as perguntas acima parecem ser:

1. Para tabelas: “Use um nome coletivo ou, menos idealmente, uma forma plural. Por exemplo (em ordem de preferência) staff e employees“. Isso foi especialmente interessante para mim. A ideia de usar um nome coletivo, e não apenas um nome plural, faz muito sentido para mim, embora não sirva para automação.
2. Para os nomes de chave primária: “Sempre que possível, evitar simplesmente usar id como o identificador primário para a tabela”. Eu vi, a partir de outra leitura, que a recomendação é usar um identificador natural como um prefixo; no caso de uma tabela posts, isso seria post_id.
3. Para tabelas de associação: “Evite, sempre que possível, concatenar dois nomes de tabelas em conjunto para criar o nome de uma tabela de relacionamento. Em vez de cars_mechanics, prefira services“. Ver isso dessa forma fez sentido para mim, e eu não me lembro de ter visto uma declaração assim antes.

Além disso, Celko estabelece uma série de sufixos uniformes para os nomes das colunas. Isso por si só é bastante interessante.

Conclusão

Se você está começando um projeto a partir do zero, e está interessados ​​em seguir o conselho de pelo menos um gigante profissional SQL e DBA, reveja as recomendações em http://www.sqlstyle.guide e faça testes. Ainda melhor, compre o livro do Celko. No mínimo, ao ler essas recomendações, você terá ganhado uma maior gama de opções para escolher.

Atenção: Se não ficou claro a partir da introdução, este exercício foi sobre a descoberta de práticas geralmente aceitas de profissionais DBA/SQL (ou seja, as pessoas cujo trabalho principal é administrar um banco de dados e escrever SQL schemas), e não as preferências dos desenvolvedores de aplicativos que por acaso usam bancos de dados SQL.

***

Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6188