En el mundo de las bases de datos, hay algunas cosas en las que se acepta universalmente. El aumento de RAM es en gran medida beneficioso para los sistemas DMBS. La distribución de datos y archivos de registro en RAID mejora el rendimiento.
Las convenciones de nomenclatura no son una de esas cosas.
Este es un tema sorprendentemente polarizador, con los defensores de varias metodologías firmemente arraigados en sus posiciones. Y muy vocal y apasionado en su defensa de la misma.
Este artículo profundizará en algunas de las convenciones específicas y los argumentos de ambos lados, mientras intenta presentar una conclusión razonable para cada punto.
El gran debate sobre la pluralización
En esencia, este es un tema simple. Por ejemplo, ¿cuál es la forma correcta de nombrar una tabla que contiene información del cliente en un esquema de base de datos relacional? ¿Es Customer? o Customers ?
Abundan los argumentos de ambos lados.
A primera vista , es natural pensar en una colección de objetos en plural. Un grupo de varias personas o empresas serían Clientes . Por lo tanto, una tabla (que es una colección de objetos) debe nombrarse en plural. Una fila individual en esa tabla sería un solo cliente .
Los principios de nomenclatura de ISO/IEC, aunque anticuados, recomiendan nombres de tablas en plural y nombres de columnas en singular.
La mayoría de las tablas del sistema de SQL Server utilizan nombres en plural (sysnotifications , operadores de sistema ), pero esto es inconsistente. Por qué sysproxylogin y no sysproxylogins ?
En los argumentos para nombres de tablas en plural, las filas de una tabla también se mencionan como "instancias" de un todo, similar a los elementos de una colección. Clientes define todo el conjunto; un único cliente es una instancia de Clientes .
Por el contrario, hay muchas razones para usar nombres de objetos singulares.
Si bien puede haber muchos artículos (o clientes ) en una tabla, la tabla en sí puede considerarse una sola entidad. caja de clientes no es “una caja de clientes”, aunque tenga un gran número de clientes dentro. Además, podría haber solo un artículo, o ninguno, dentro de la tabla, lo que hace que "clientes" sea un nombre inapropiado.
Si elige modificar el nombre de la tabla en función de las variantes de palabras, pueden surgir incoherencias rápidamente. Si bien muchas palabras serán sencillas (Cliente se convierte en Clientes , Producto se convierte en Productos ), otras palabras pueden no serlo. En este caso, Persona podría convertirse en Personas o Personas; un singular Alce se vería igual que su forma plural, Moose . (Aunque, ¿por qué necesitarías una tabla de alces?) Una convención como Personas.Nombre comienza a volverse confuso y poco claro.
Si hay varios idiomas involucrados, la situación empeora aún más. Debido a que la pluralización de palabras puede variar de muchas maneras (clientes, ratones, alces, niños, crisis, planes de estudio, aviones), los hablantes no nativos tienen desafíos adicionales. Seguir con nombres de objetos singulares evita este problema por completo.
La pregunta de la convención del caso
No hay el mismo fervor con las convenciones de casos que con la pluralización, pero se hacen argumentos para varias opciones diferentes. Incluyen:
- Caso Pascal :La primera letra de cada palabra concatenada está en mayúscula, como en:
CustomerOrder -
Estuche camello :La primera letra de la primera palabra es minúscula; todas las palabras concatenadas posteriores tienen una primera letra en mayúscula, como en:
customerOrderPascal Case a veces se considera un subtipo de Camel Case, pero Microsoft generalmente diferencia entre los dos.
Para palabras de menos de tres caracteres, se recomienda usar solo mayúsculas, como en
UIoIO. - Guión bajo [Caso “C”] :Las palabras se separan con guiones bajos, como en
Customer_Order, ocustomer_Order– ¡aún más decisiones!
Investigadores de la Universidad Johns Hopkins realizaron un estudio sobre la eficiencia del uso de guiones bajos en la programación de nombres de objetos. Descubrieron que el uso de Camel Case (o Pascal Case) mejoraba la precisión y el reconocimiento de la escritura. Los guiones bajos se usaban ampliamente en la programación en C, pero la tendencia es hacia Camel/Pascal Case con un énfasis reciente en los lenguajes de estilo Microsoft y Java.
Al igual que con los otros temas, los siguientes una convención establecida es más importante que la selección de la propia convención.
Una consideración adicional aquí es la distinción entre mayúsculas y minúsculas de la base de datos. La intercalación de SQL Server determina esta sensibilidad con 'CS' (distingue entre mayúsculas y minúsculas) o 'CI' (insensible a mayúsculas y minúsculas) en el nombre de intercalación. Por ejemplo:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
En intercalaciones que distinguen entre mayúsculas y minúsculas, Select * from myTable fallaría contra el objeto MyTable . Esto puede hacer que los guiones bajos sean ligeramente preferibles para evitar confusiones, pero Intellisense también ayuda a eliminar los errores de tipeo en la mayoría de los entornos de programación modernos.
Otras consideraciones sobre la convención de nomenclatura
El debate Singular vs. Plural y la gran pregunta del caso pueden ser donde la batalla es más feroz, pero hay al menos tres áreas más a tener en cuenta al considerar una convención de nomenclatura.
Evite utilizar palabras reservadas de SQL Server como nombres de objetos. Esto incluye tablas y columnas. Por ejemplo:Usuario , Tiempo y Fecha están reservados. Las palabras clave reservadas pueden requerir un cuidado adicional para hacer referencia (como el uso de corchetes) según la aplicación que llama. Esto también se aplica a los espacios. Los espacios en los nombres de objetos requieren comillas para hacer referencia.
Esto también se relaciona con otra recomendación:precisión. Sistema.CrearFecha es mucho más claro que System.Date . Un modelo bien diseñado permite al espectador comprender de inmediato el propósito de los objetos subyacentes. Cuando se deba hacer referencia a cualquier identificador como clave externa, sea liberal en el nombre:Customer.CustomerID en lugar de Customer.ID .
Evitar prefijos y sufijos para tablas y vistas , como tblTable . La notación húngara (que siempre tuvo la intención de identificar el uso de variables) se deslizó en las convenciones de nomenclatura comunes de SQL Server, pero es ampliamente ridiculizada. Los identificadores de objetos deben describir lo que contienen, no el objeto en sí.
Sin embargo, los prefijos son útiles en objetos compatibles con SQL Server , ya que describen la naturaleza funcional del objeto.
Los siguientes son prefijos comúnmente aceptados para objetos de SQL Server:
- IX:Índice
- PK:clave principal
- FK:clave foránea
- CK:Comprobar restricción
- DF:Predeterminado
- UQ también se usa a veces para índices únicos.
Este modelo ilustra los puntos definidos anteriormente. No requiere explicación en cuanto a la naturaleza de los datos; se usan convenciones de nomenclatura singulares y se implementan identificadores claros.
Al final, hay ventajas y desventajas para cada lado del debate de nombres de convenciones. Sin embargo, hay un punto clave en el que ambas partes pueden estar de acuerdo:independientemente de las decisiones que se tomen, sea coherente con la convención seleccionada.
¿Qué convenciones de nomenclatura de SQL utiliza y por qué?
