practices name index columns column best sql sql-server naming-conventions

index - sql table names convention



Tabla de nombres de dilema: Singular vs. Plural Names (30)

La Academia dice que los nombres de las tablas deben ser el singular de la entidad de la que almacenan los atributos.

No me gusta ningún T-SQL que requiera corchetes alrededor de los nombres, pero he cambiado el nombre de una tabla de Users al singular, siempre sentenciándolos a aquellos que usan la tabla para que a veces tengan que usar corchetes.

Mi intuición es que es más correcto permanecer con el singular, pero mi intuición es también que los paréntesis indican indeseables como nombres de columnas con espacios en ellos, etc.

¿Debo permanecer o debo ir?

¿Qué convención requiere que las tablas tengan nombres singulares? Siempre pensé que eran nombres en plural.

Se agrega un usuario a la tabla Usuarios.

Este sitio acepta:
http://vyaskn.tripod.com/object_naming.htm#Tables

Este sitio no está de acuerdo (pero no estoy de acuerdo con él):
http://justinsomnia.org/writings/naming_conventions.html

Como otros han mencionado: estas son solo pautas. Elija una convención que funcione para usted y su empresa / proyecto y apéguese a ella. Cambiar entre palabras singulares y plurales o, a veces, abreviadas, ya veces no, es mucho más agravante.

¿Qué tal esto como un simple ejemplo?

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

contra

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

El SQL en este último es más extraño que el anterior.

Voto por singular .

Creo firmemente que en un Diagrama de relación de entidad, la entidad debe reflejarse con un nombre singular, similar a un nombre de clase que es singular. Una vez instanciado, el nombre refleja su instancia. Así que con las bases de datos, la entidad cuando se convierte en una tabla (una colección de entidades o registros) es plural. Entidad, el usuario se convierte en usuarios de la tabla. Estoy de acuerdo con otras personas que sugirieron que tal vez el nombre de Usuario podría mejorarse para Empleado o algo más aplicable a su escenario.

Esto entonces tiene más sentido en una declaración SQL porque está seleccionando de un grupo de registros y si el nombre de la tabla es singular, no se lee bien.

Ejecutamos estándares similares, cuando los scripts exigimos [] alrededor de los nombres y, cuando corresponde, los calificadores de esquema, principalmente cubren sus apuestas contra las futuras tomas de nombres por la sintaxis SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = ''WA''

Esto ha salvado nuestras almas en el pasado, algunos de nuestros sistemas de bases de datos se han ejecutado más de 10 años desde SQL 6.0 hasta SQL 2005, más allá de la vida útil prevista.

En mi humilde opinión, los nombres de las tablas deben ser plurales como Clientes .

Los nombres de clase deben ser singulares, como Cliente, si se asigna a una fila en la tabla Clientes .

En realidad, siempre he pensado que era una convención popular utilizar nombres de tablas plurales. Hasta este punto siempre he usado plural.

Puedo entender el argumento de los nombres de tablas singulares, pero para mí el plural tiene más sentido. Un nombre de tabla generalmente describe lo que contiene la tabla. En una base de datos normalizada, cada tabla contiene conjuntos específicos de datos. Cada fila es una entidad y la tabla contiene muchas entidades. Así, la forma plural para el nombre de la tabla.

Una tabla de autos tendría el nombre de carros y cada fila es un carro. Admito que la mejor práctica es especificar la tabla junto con el campo de forma de tabla y campo y que tener nombres de tabla singulares es más legible. Sin embargo, en los siguientes dos ejemplos, el primero tiene más sentido:

SELECT * FROM cars WHERE color=''blue'' SELECT * FROM car WHERE color=''blue''

Honestamente, estaré reconsiderando mi posición sobre el tema y me basaré en las convenciones reales utilizadas por la organización para la que estoy desarrollando. Sin embargo, creo que para mis convenciones personales, me quedo con los nombres de tabla plural Para mí tiene más sentido.

Me quedo con singular para nombres de tabla y cualquier entidad de programación.

¿La razón? El hecho de que hay plurales irregulares en inglés como ratón ⇒ ratones y ovejas ⇒ ovejas . Luego, si necesito una colección , solo uso mouses o sheeps y sigo adelante.

Realmente ayuda a que la pluralidad se destaque, y puedo determinar fácil y programáticamente cómo se vería la colección de cosas.

Entonces, mi regla es: todo es singular, cada colección de cosas es singular con una letra anexada. Ayuda con ORMs también.

No me gustan los nombres de tablas plurales porque algunos nombres en inglés no son contables (agua, sopa, dinero en efectivo) o el significado cambia cuando se hace contable (pollo contra pollo, carne contra pájaro). También me disgusta usar abreviaturas para el nombre de la tabla o el nombre de la columna porque hacerlo agrega una pendiente extra a la curva de aprendizaje ya empinada.

Irónicamente, podría hacer que el User una excepción y lo llame Users debido a USER (Transac-SQL) , porque tampoco me gusta usar corchetes en las tablas si no tengo que hacerlo.

También me gusta nombrar todas las columnas de ID como Id , no ChickenId o ChickensId (¿qué hacen los chicos plurales sobre esto?).

Todo esto se debe a que no tengo el debido respeto por los sistemas de base de datos, solo estoy volviendo a aplicar el conocimiento de un solo truco de las convenciones de nomenclatura OO como Java''s por hábito y flojera. Me gustaría que hubiera un mejor soporte IDE para SQL complicado.

Otros han dado respuestas bastante buenas en cuanto a los "estándares", pero solo quería agregar esto ... ¿Es posible que "Usuario" (o "Usuarios") no sea realmente una descripción completa de los datos contenidos en la tabla? ? No es que deba volverse demasiado loco con los nombres y la especificidad de las tablas, pero quizás algo como "Widget_Users" (donde "Widget" es el nombre de su aplicación o sitio web) sería más apropiado.

Personalmente prefiero usar nombres plurales para representar un conjunto, simplemente "suena" mejor para mi mente relacional.

En este momento exacto, estoy usando nombres singulares para definir un modelo de datos para mi empresa, porque la mayoría de las personas en el trabajo se sienten más cómodas con él. A veces solo tienes que hacer la vida más fácil para todos en lugar de imponer tus preferencias personales. (Así es como terminé en este hilo, para obtener una confirmación de lo que debería ser la "mejor práctica" para nombrar tablas)

Después de leer todas las discusiones en este hilo, llegué a una conclusión:

Me gustan mis panqueques con miel, sin importar cuál sea el sabor favorito de todos. Pero si estoy cocinando para otras personas, trataré de servirles algo que les guste.

Prefiero usar el nombre sin inflexión , que en inglés resulta ser singular.

La desviación del número del nombre de la tabla causa problemas ortográficos (como lo muestran muchas de las otras respuestas), pero elegir hacerlo porque las tablas generalmente contienen varias filas también está semánticamente llena de agujeros. Esto es más obvio si consideramos un lenguaje que tuerce los sustantivos según el caso (como la mayoría).

Ya que usualmente estamos haciendo algo con las filas, ¿por qué no poner el nombre en el caso acusativo? Si tenemos una tabla en la que escribimos más de lo que leemos, ¿por qué no poner el nombre en dativo? Es una tabla de algo, ¿por qué no usar el genitivo? No haríamos esto, porque la tabla se define como un contenedor abstracto que existe independientemente de su estado o uso. La inflexión del sustantivo sin una razón semántica precisa y absoluta es balbuceo.

El uso del sustantivo sin inflexión es simple, lógico, regular e independiente del lenguaje.

Si usa herramientas de Mapeo Relacional de Objetos o lo hará en el futuro, sugiero Singular .

Algunas herramientas como LLBLGen pueden corregir automáticamente nombres plurales como Usuarios a Usuario sin cambiar el nombre de la tabla. ¿Por qué esto importa? Porque cuando se asigna, desea que se vea como User.Name en lugar de Users.Name o, lo que es peor, en algunas de mis tablas de bases de datos antiguas que dan nombre a tblUsers.strName, lo cual es simplemente confuso en el código.

Mi nueva regla de oro es juzgar cómo se verá una vez que se haya convertido en un objeto.

Una tabla que encontré que no se ajusta a la nueva denominación que uso es UsersInRoles. Pero siempre habrá esas pocas excepciones e incluso en este caso se ve bien como UsersInRoles.Username.

Singular. Llamaría a una matriz que contiene un grupo de objetos de representación de filas de usuarios ''usuarios'', pero la tabla es ''la tabla de usuarios''. Pensar que la tabla no es más que el conjunto de las filas que contiene es incorrecto, OMI; La tabla es los metadatos, y el conjunto de filas está unido jerárquicamente a la tabla, no es la tabla en sí.

Por supuesto, uso ORM todo el tiempo, y ayuda a que el código ORM escrito con nombres de tablas plurales parezca estúpido.

Singular. No compro ningún argumento que implique lo más lógico: cada persona piensa que su preferencia es lo más lógico. No importa lo que hagas, es un desastre, solo elige una convención y apégate a ella. Estamos tratando de mapear un lenguaje con gramática y semántica altamente irregular (lenguaje hablado y escrito normal) a una gramática altamente regular (SQL) con semántica muy específica.

Mi argumento principal es que no pienso en las tablas como un conjunto sino como relaciones.

Por lo tanto, la relación de AppUser indica qué entidades son AppUsers .

La relación AppUserGroup me dice qué entidades son AppUserGroups

La relación AppUser_AppUserGroup me dice cómo se relacionan AppUsers y AppUserGroups .

La relación AppUserGroup_AppUserGroup me dice cómo se relacionan AppUserGroups y AppUserGroups (es decir, grupos miembros de grupos).

En otras palabras, cuando pienso en entidades y cómo se relacionan, pienso en relaciones en singular, pero, por supuesto, cuando pienso en entidades en colecciones o conjuntos, las colecciones o conjuntos son plurales.

En mi código, entonces, y en el esquema de la base de datos, uso singular. En las descripciones textuales, termino usando plural para mejorar la legibilidad, luego uso fuentes, etc. para distinguir el nombre de la tabla / relación del plural s.

Me gusta pensar que es complicado, pero sistemático, y de esta manera siempre hay un nombre generado de manera sistemática para la relación que deseo expresar, lo que para mí es muy importante.

Soy un fanático de los nombres de tablas singulares, ya que hacen que los diagramas de mi ER utilizando la sintaxis de CASE sean más fáciles de leer, pero al leer estas respuestas tengo la sensación de que nunca se entendió muy bien. Personalmente me encanta. Hay una buena descripción general con ejemplos de lo legibles que pueden ser sus modelos cuando usa nombres de tablas singulares, agrega verbos de acción a sus relaciones y forma oraciones buenas para cada relación. Todo es un poco excesivo para una base de datos de 20 tablas, pero si tiene una base de datos con cientos de tablas y un diseño complejo, ¿cómo lo entenderán sus desarrolladores sin un buen diagrama legible?

http://www.aisintl.com/case/method.html

En cuanto al prefijo de tablas y vistas, odio esa práctica. No le dé ninguna información a una persona antes de darles posiblemente mala información. Cualquier persona que busque objetos en la base de datos puede distinguir fácilmente una tabla desde una vista, pero si tengo una tabla llamada tblUsers, por alguna razón, decido reestructurarme en el futuro en dos tablas, con una vista que los unifique para evitar romper el código antiguo Ahora tengo una vista llamada tblUsers. En este punto, me quedan dos opciones poco atractivas, dejar una vista con un prefijo tbl que pueda confundir a algunos desarrolladores, o forzar que otra capa, ya sea nivel intermedio o aplicación, sea reescrita para hacer referencia a mi nueva estructura o nombre de usuarios de visualización. Eso niega una gran parte del valor de las vistas en mi humilde opinión.

También me gustaría ir con los plurales , y con el dilema de Usuarios mencionado anteriormente, tomamos el enfoque de corchetes.

Hacemos esto para proporcionar uniformidad entre la arquitectura de la base de datos y la arquitectura de la aplicación, con el entendimiento subyacente de que la tabla de Usuarios es una colección de valores de Usuario , así como una colección de Usuarios en un artefacto de código es una colección de objetos de Usuario .

Tener a nuestro equipo de datos y nuestros desarrolladores hablando el mismo lenguaje conceptual (aunque no siempre los mismos nombres de objetos) hace que sea más fácil transmitir ideas entre ellos.

Tuve la misma pregunta, y después de leer todas las respuestas aquí definitivamente me quedo con SINGULAR, razones:

Razón 1 (Concepto). Puedes pensar en una bolsa que contiene manzanas como "AppleBag", no importa si contiene 0, 1 o un millón de manzanas, siempre es la misma bolsa. Las tablas son solo eso, contenedores, el nombre de la tabla debe describir lo que contiene, no la cantidad de datos que contiene. Además, el concepto plural tiene más que ver con un idioma hablado (en realidad para determinar si hay uno o más).

Razón 2 . (Conveniencia). es más fácil salir con nombres singulares, que con nombres plurales. Los objetos pueden tener plurales irregulares o no plural, pero siempre tendrán uno singular (con pocas excepciones como Noticias).

  • Cliente
  • Orden
  • Usuario
  • Estado
  • Noticias

Razón 3 . (Estética y orden). Especialmente en escenarios de detalle maestro, esto se lee mejor, se alinea mejor por nombre y tiene un orden más lógico (Maestro primero, Detalle segundo):

  • 1. Orden
  • 2.OrderDetail

Comparado con:

  • 1.OrderDetails
  • 2 órdenes

Razón 4 (Sencillez). Poner todos juntos, Nombres de tablas, Claves primarias, Relaciones, Clases de entidad ... es mejor conocer solo un nombre (singular) en lugar de dos (clase singular, tabla plural, campo singular, detalle maestro singular-plural ... .)

  • Customer
  • Customer.CustomerID
  • CustomerAddress
  • public Class Customer {...}
  • SELECT FROM Customer WHERE CustomerID = 100

Una vez que sepa que está tratando con "Cliente", puede estar seguro de que usará la misma palabra para todas sus necesidades de interacción con la base de datos.

Razón 5 . (Globalización). El mundo se está reduciendo, es posible que tenga un equipo de diferentes nacionalidades, no todos tienen el inglés como idioma nativo. Sería más fácil para un programador no nativo del idioma inglés pensar en "Repositorio" que en "Repositorios" o "Estados" en lugar de "Estado". Tener nombres singulares puede llevar a menos errores causados ​​por errores tipográficos, ahorrar tiempo al no tener que pensar "¿es niño o niños?", Lo que mejora la productividad.

Razón 6 . (¿Por qué no?). ¡Incluso puede ahorrarle tiempo de escritura, espacio en el disco e incluso hacer que el teclado de su computadora dure más!

  • SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
  • SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Has guardado 3 letras, 3 bytes, 3 golpes de teclado adicionales :)

Y, por último, puede nombrar a aquellos que cometen errores con nombres reservados como:

  • Usuario> LoginUser, AppUser, SystemUser, CMSUser, ...

O use los infames corchetes [Usuario]

Posibles alternativas:

  • Renombrar la tabla SystemUser
  • Utilizar soportes
  • Mantener los nombres de las tablas en plural.

El uso de corchetes IMO es técnicamente el enfoque más seguro, aunque es un poco engorroso. En mi opinión, es 6 de una, media docena de la otra, y su solución realmente se reduce a las preferencias personales / de equipo.

Solo uso nombres para los nombres de mis tablas que se escriben igual, ya sea en singular o en plural:

alce pez ciervo avioneta pantalones cortos anteojos tijeras especies descendencia

Tablas: plural

Varios usuarios se enumeran en la tabla de usuarios.

Modelos: singular

Se puede seleccionar un usuario singular de la tabla de usuarios.

Controladores: plural

http://myapp.com/users listaría múltiples usuarios.

Esa es mi opinión de todos modos.

Como otros han mencionado aquí, las convenciones deben ser una herramienta para aumentar la facilidad de uso y la legibilidad. No como un grillete o un club para torturar a los desarrolladores.

Dicho esto, mi preferencia personal es usar nombres singulares para tablas y columnas. Esto probablemente viene de mi fondo de programación. Los nombres de las clases son generalmente singulares, a menos que sean algún tipo de colección. En mi mente, estoy almacenando o leyendo registros individuales en la tabla en cuestión, por lo que el singular tiene sentido para mí.

Esta práctica también me permite reservar nombres de tablas plurales para aquellos que almacenan relaciones de muchos a muchos entre mis objetos.

Trato de evitar las palabras reservadas en mis nombres de tabla y columna, también. En el caso en cuestión aquí tiene más sentido ir en contra de la convención singular de los usuarios para evitar la necesidad de encapsular una tabla que utiliza la palabra reservada de usuario.

Me gusta usar los prefijos de manera limitada (tbl para nombres de tablas, sp_ para nombres proc, etc.), aunque muchos creen que esto agrega desorden. También prefiero los nombres de CamelBack a los guiones bajos porque siempre termino presionando el + en lugar de _ al escribir el nombre. Muchos otros no están de acuerdo.

Aquí hay otro buen enlace para nombrar las pautas de la convención: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

Recuerde que el factor más importante en su convención es que tiene sentido para las personas que interactúan con la base de datos en cuestión. No hay un "Un Anillo para Gobernarlos Todos" cuando se trata de nombrar convenciones.

Creo que usar el singular es lo que nos enseñaron en la universidad. Pero al mismo tiempo podría argumentar que a diferencia de la programación orientada a objetos, una tabla no es una instancia de sus registros.

Creo que me estoy inclinando por el singular en este momento debido a las irregularidades plurales en inglés. En alemán es aún peor debido a que no hay formas plurales consistentes - a veces no se puede saber si una palabra es plural o no sin el artículo específico delante de él (der / die / das). Y en los idiomas chinos no hay formas plurales de todos modos.

El sistema tables/viewsdel servidor en sí ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, etc.) son casi siempre plural. Supongo que por coherencia seguiría su ejemplo.

Esto puede ser un poco redundante, pero sugeriría ser cauteloso. No necesariamente es algo malo cambiar el nombre de las tablas, pero la estandarización es solo eso; un estándar - esta base de datos ya puede estar "estandarizada", aunque mal :) - Sugeriría coherencia para ser un mejor objetivo dado que esta base de datos ya existe y, presumiblemente, consta de más de 2 tablas.

A menos que pueda estandarizar toda la base de datos, o al menos esté planeando trabajar para ese fin, sospecho que los nombres de las tablas son solo la punta del iceberg y se concentran en la tarea en cuestión, soportando el dolor de los objetos mal nombrados, puede estar en su mejor interés -

La consistencia práctica a veces es el mejor estándar ... :)

my2cents ---

La definición de SQL de una tabla es en realidad la definición de una fila potencial de la tabla, no la colección. Por lo tanto, el nombre utilizado en esa definición debe designar el tipo de fila, no el nombre de la colección. Las personas que prefieren el plural porque se lee bien en sus declaraciones en inglés deben comenzar a pensar de forma más lógica y observar toda la lógica y el código de programación que implica el uso de una tabla. Hay varias razones muy buenas mencionadas en estos comentarios para usar nombres de tablas singulares. Estos incluyen muy buenas razones para NO usar nombres de tablas plurales. "Leer bien" no debería ser ninguna razón, especialmente porque algunos pueden leer la idea de manera diferente.

Mi opinión es en semántica según cómo defina su contenedor. Por ejemplo, una "bolsa de manzanas" o simplemente "manzanas" o una "bolsa de manzanas" o "manzana".

Ejemplo: una tabla "universidad" puede contener 0 o más universidades una tabla de "universidades" puede contener 0 o más universidades

a "student" table can contain 0 or more students a table of "students" can contain 0 or more students.

Mi conclusión es que cualquiera de los dos está bien, pero tiene que definir cómo se acercarán usted (o las personas que interactúan con él) al referirse a las tablas; "tabla ax" o una "tabla de xs"

Si nos fijamos en las MS SQL Server''stablas del sistema, sus nombres asignados por Microsoft están en plural.

Las tablas del sistema de Oracle se nombran en singular. Aunque algunos de ellos son plurales. Oracle recomienda plural para los nombres de tablas definidos por el usuario. Eso no tiene mucho sentido que recomienden una cosa y siguen otra. Que los arquitectos de estos dos gigantes del software hayan nombrado sus tablas con diferentes convenciones, tampoco tiene mucho sentido ... Después de todo, ¿qué son estos tipos ... PhD?

Recuerdo en la academia, la recomendación fue singular.

Por ejemplo, cuando decimos:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = ''ABC123''

tal vez b / c cada uno IDse selecciona de una sola fila en particular ...?

Siempre he usado singular, simplemente porque eso es lo que me enseñaron. Sin embargo, al crear un nuevo esquema recientemente, por primera vez en mucho tiempo, decidí activamente mantener esta convención simplemente porque ... es más corto. Agregar una ''s'' al final de cada nombre de tabla me parece tan inútil como agregar ''tbl_'' delante de cada una.

Siempre pensé que era una convención tonta. Yo uso nombres de tablas en plural.

(Creo que lo racional detrás de esa política es que hace que sea más fácil para los generadores de código ORM producir clases de objetos y colecciones, ya que es más fácil producir un nombre en plural a partir de un nombre singular que al revés)

Una vez usé "Dude" para la tabla de usuario: el mismo número de caracteres, sin conflicto con las palabras clave, sigue siendo una referencia a un humano genérico. Si no estuviera preocupado por las cabezas tapadas que podrían ver el código, lo habría mantenido así.