Dilema de nombres de tablas: nombres singulares vs. plurales [cerrado]


1467

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 Userstabla al singular, condenando para siempre a aquellos que usan la tabla a veces tienen que usar corchetes.

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

¿Debo permanecer o debo ir?


Dup de los nombres de tablas de base de datos anteriores , plural o singular , pero este llamó más la atención.
outis

77
Me sorprende que más personas no digan: está determinado por lo que representa una sola fila. En una sola base de datos, puedo tener una tabla cuyas filas representan un solo widget único, y otra relación de uno a muchos con esa tabla significa que las filas representan muchos widgets. No hacer esto pierde expresividad.
andygavin

1
Solo quiero agregar eso en todas estas discusiones, tenga en cuenta que una tabla de ninguna manera forma o forma lo mismo que una clase. Una tabla es una colección de elementos de un tipo específico que se pueden ordenar, consultar, etc., en propiedades individuales. Una clase es el marco para describir las propiedades y el comportamiento de un tipo específico. En términos de codificación OO, la representación cerrada de una tabla es una colección de objetos (no importa qué ORM pueda estar usando). Esta es, con mucho, la respuesta de Google de más alto rango en este tema, por lo que aunque la pregunta está cerrada, la página aún tiene valor.

1
Me gustaría seguir la práctica común del ecosistema en el que está trabajando. Por ejemplo: en Node.js, los ORM como Bookshelf.js u Objection.js se basan principalmente en "Knex.js". Y en la documentación de "Knex.js" encontrará nombres de tablas en plural. Entonces iría por el plural en ese dominio. Fuente: knexjs.org/#Schema-createTable
Benny Neugebauer

2
Sí estoy de acuerdo. Tiene sentido tener una tabla de usuarios y llamarla "AppUser" al mismo tiempo, también tiene sentido tener una tabla de reglas aplicable a un tipo particular de usuario y llamarla "UserRules"
Arindam

Respuestas:


242

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


77
Estoy de acuerdo. OrgUsers, AppUsers, cualquier cosa para evitar usar una palabra clave.
MikeW

77
-1. Los usuarios de tablas (y países, idiomas) se pueden usar en pocas aplicaciones simultáneamente.
OZ_

129129
¿Asociar el nombre del esquema no eliminaría toda la confusión? AppName1.Users, AppName2.Users?
Zo tiene

77
No estoy de acuerdo con el prefijo de la tabla: ¿quizás debería ser un esquema? - pero estoy de acuerdo con un "nombre más descriptivo". Incluso algo tan simple como "AppUser" sería suficiente, sin entrar en todo el debate del espacio de nombres.

77
Esta respuesta aceptada es más un comentario secundario y no responde la pregunta.
Viliami

1826

Tenía 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 contenga 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 cuántos datos contiene. Además, el concepto plural se trata más de un lenguaje 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 los plurales. Los objetos pueden tener plurales irregulares o no plurales en absoluto, 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 detalles maestros, esto se lee mejor, se alinea mejor por nombre y tiene un orden más lógico (Primero maestro, Detalle segundo):

  • 1 orden
  • 2.Detalles del pedido

Comparado con:

  • 1.Detalles del pedido
  • 2 órdenes

Razón 4 (simplicidad). Poner todo junto, nombres de tabla, claves primarias, relaciones, clases de entidad ... es mejor tener en cuenta 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á volviendo más pequeño, puede tener un equipo de diferentes nacionalidades, no todos tienen el inglés como lengua materna. Sería más fácil para un programador de lengua no inglesa pensar en "Repositorio" que en "Repositorios", o "Estado" en lugar de "Estados". Tener nombres singulares puede conducir a menos errores causados ​​por errores tipográficos, ahorrar tiempo al no tener que pensar "¿es niño o niños?", Mejorando así la productividad.

Razón 6 . (¿Por qué no?). ¡Incluso puede ahorrarle tiempo de escritura, ahorrar espacio en 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 finalmente, puede nombrar a aquellos que se equivocan con nombres reservados como:

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

O use los infames corchetes [Usuario]


625
Apuesto a que si pones una etiqueta en un cajón de calcetines lo llamarías "Calcetines".
Chris Ward

73
Definitivamente Es difícil obtener un estándar que funcione para todos y para todos, lo importante es que funcione para usted. Esto funciona para mí, y aquí he explicado por qué, pero de nuevo, eso es para mí, y lo encuentro muy conveniente.
Nestor

451
La pregunta más importante, Chris, es ¿por qué seguirías las convenciones de nombres de bases de datos al nombrar un cajón de calcetines?
Kyle Clegg

83
Esta respuesta necesita más elogios. Discute un montón de razones prácticas que aplico por las que prefiero nombres singulares. Las discusiones alternativas sobre el lenguaje apropiado en referencia a los conjuntos son simplemente filosóficas y oscurecen el punto real. Singular simplemente funciona mejor.
Jason

298
Tengo un cajón "Sock" en casa, no un cajón "Socks". Si fuera una base de datos, la llamaría la tabla "Sock".
jlembke

260

Si utiliza 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é importa esto? Porque cuando está mapeado, quiere que se vea como User.Name en lugar de Users.Name o peor de algunas de mis tablas de bases de datos antiguas que nombran tblUsers.strName, que es simplemente confuso en el código.

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

Una tabla que he encontrado que no se ajusta al nuevo nombre que uso es UsersInRoles. Pero siempre habrá esas pocas excepciones e incluso en este caso se ve bien como UsersInRoles.Username.


48
He votado en contra y le diré por qué, porque no estoy de acuerdo. ORM por su propia naturaleza se trata de mapeo. Cada herramienta ORM que he usado admite la especificación del nombre de la tabla que se utilizará para una entidad cuando es diferente del nombre de la entidad. Esto es importante porque toda la razón por la que asignamos bases de datos relacionales es para que podamos realizar fácilmente consultas e informes ad-hoc con formas diferentes que nuestro modelo de objetos. De lo contrario, ya estaríamos utilizando bases de datos de objetos / documentos.
joshperry

25
El ORM no debe dictar los nombres de los objetos a los que se asignan. El punto de ORM es una abstracción del objeto, otorgando esta flexibilidad.
barrypicker

19
En mi mundo, trato de usar nombres consistentes en todo el proyecto para evitar perder el tiempo preguntándome si esta instancia tiene una s al final o no. El hecho de que un ORM pueda renombrar y ser independiente no significa que hacerlo ayude a sus colegas desarrolladores.
John Nicholas

2
Algunos ORM (como muchas herramientas de programación) tienen un comportamiento predeterminado que genera implementaciones sin configuración ... con el punto de venta de PRODUCTIVIDAD. Por lo tanto, crear una clase Employee, sin mapeo explícito, generaría una tabla Employee de forma predeterminada
user919426,

1
@barrypicker. Los nombres en plural no solo parecen tontos en el código ORM. Los plurales también se ven mal en SQL, especialmente cuando se refieren a un atributo único. ¿Quién nunca ha escrito select user.id de los usuarios? O tal vez ... de los usuarios que quedan unirse a thingy.user_id = user.id ...?
Samuel Danielson

219

Prefiero usar el sustantivo no flexionado , que en inglés resulta ser singular.

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

Como generalmente 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. Reflejar el sustantivo sin una razón semántica precisa y absoluta es un balbuceo.

El uso del sustantivo no flexionado es simple, lógico, regular e independiente del idioma.


37
Probablemente el argumento más lógico sobre este tema que he visto, y me alegra haber pasado ese tiempo en latín. +1 seguro.

52
Bueno, claramente necesito reforzar mi vocabulario.
TJ Biddle

19
+1 Mira, estos son los tipos de respuestas que Internet necesita más. Pruebas impecables utilizando un vocabulario rico para ejecutar una lógica perfecta.
OCDev

8
Tomaré nota de esto la próxima vez que programe en latín. Mientras tanto, los usuarios irán a la tabla de usuarios y los clientes a la tabla de clientes.
Caltor

8
Convencido, sin inflexión, lo es. Es interesante ver que, después de todo este tiempo, las opciones populares de "singular" y "plural" son tanto mal!
Stuart

126

¿Qué convención requiere que las tablas tengan nombres singulares? Siempre pensé que se trataba de nombres plurales.

Se agrega un usuario a la tabla Usuarios.

Este sitio está de acuerdo:
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 cúmplala. Cambiar entre palabras singulares y plurales o a veces abreviadas y a veces no es mucho más agravante.


46
Cuando se aplica la teoría de conjuntos a las tablas, cualquier instancia en el conjunto es representativa del conjunto, por lo que Apple es un conjunto de Apple, es independiente de cuántas manzanas hay en el conjunto; es una Apple con muchas instancias. Una 'bolsa' de manzanas no se convierte en una 'bolsa' cuando contiene muchas manzanas.
ProfK

89
¿Qué pasa si tienes una bolsa con 5 manzanas adentro? ¿Lo llamas una bolsa de manzana? o una bolsa de manzanas?
Christopher Mahan el

26
Creo que la teoría sería que el conjunto se llama Manzanas. Una manzana singular sigue siendo "un conjunto de manzanas", aunque sea un conjunto con una sola instancia. Las manzanas múltiples también son un "conjunto de manzanas".
Mark Brackett el

26
@Christopher, si la razón de ser de la bolsa es contener manzanas y solo manzanas, entonces es una "bolsa de manzanas", independientemente de si contiene 1 manzana, 100 manzanas o ninguna manzana.
Ian Mackinnon el

14
@ Ian: Eso se debe a que una mesa es genérica y se puede comparar con un contenedor de envío (puede contener casi cualquier cosa, desde cajas de manzanas hasta cajas de motocicletas Harley Davidson). Usted dice: un contenedor de carga de naranjas, no un contenedor de carga naranja. Usted dice: un contenedor de carga de piezas de automóviles, no un contenedor de carga de piezas de automóviles. Si creó una estructura de datos personalizada destinada a contener solo un tipo específico de datos, como nombres de manzanas, y la llamó "kungabogo", entonces podría tener una manzana kungaboko. Sé lo que piensas, pero primero piensa en un saco de bolas y entiendo la diferencia de significado.
Christopher Mahan

79

¿Qué tal esto como un simple ejemplo:

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

vs.

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

El SQL en este último suena más extraño que el primero.

Yo voto por el singular .


50
En ese ejemplo, sí, pero en sql práctico nunca se escribiría de esa manera. Tendrías un alias de la tabla por lo que sería más comoSELECT C.Name, C.Address FROM Customers WHERE Customers.Name > 'def'
Michael Haren

+1, (un año después) Citó un ejemplo TERRÍFICO sobre cómo el singular tiene sentido. Esto es algo un debate religioso. Hace varios años, un arquitecto de datos me convirtió en el singular, muchos años mayor que yo, y me pareció correcto (después de haber requerido mucho para convencerme de cambiar).
Chris Adragna

24
Creo que el sql suena mejor en plural. No tendría nombres de tabla para cada columna, ¿por qué le gusta escribir tanto? SELECCIONE el nombre, la dirección de los clientes DONDE Nombre> "def" Está seleccionando del grupo de clientes donde el nombre es mayor que def.
Jamiegs

66
¿Qué tal usar un alias / AS para solucionar ese problema? SELECCIONE Customer.Name, Customer.Address FROM Clientes COMO Customer WHERE Customer.Name> "def"
James Hughes

1
El segundo suena mucho mejor, suena singular como alguien que no puede hablar inglés.
HLGEM

61

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 sea singular. Una vez instanciado, el nombre refleja su instancia. Entonces, 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 la tabla Usuarios. Estoy de acuerdo con otros que sugirieron que tal vez el nombre Usuario podría mejorarse a Empleado o algo más aplicable a su escenario.

Esto 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.


3
Me gusta especialmente el comentario de la declaración SQL. Usar singular aquí no se siente intuitivo para el lector.
hochl

2
Excelente punto sobre el ERD. Sospecho que es por eso que, para alguien que ve el mundo a través de los ojos del DBA, los nombres singulares tienen sentido. Sospecho que no entienden, como usted señala, la diferencia entre una entidad y una colección de ellos.
William T. Mallard

1
Una tabla no es una colección de registros; una tabla es una definición de cómo se ve un registro. Esa es la desconexión que toda la gente plural / singular parece tener.
rico remer

No estoy de acuerdo con el comentario de la declaración SQL. ¿Qué pasa si quieres unirte contra los usuarios
tabla hash

1
Una anciana tiene muchos gatos O las ancianas tienen gatos. Creo que los ERD se leen mejor como plural. Y la tabla de entidades, las tablas tienen muchas entidades, así que nuevamente creo que el plural suena bien.
user3121518

39

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

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

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

Entonces, mi regla es: todo es singular, cada colección de cosas es singular con un s adjunto. Ayuda con ORM también.


77
¿Qué tal una palabra que termina con una 's'? Si tiene una tabla llamada 'Noticias' (solo como ejemplo), ¿cómo llamaría a la colección de noticias? Newss? ¿O llamarías a la mesa 'Nuevo'?
Anthony

18
Llamaría a la tabla NewsItem y a una colección NewsItems.
Ash Machine

55
¿Qué sucede si tiene que revisar la ortografía de todo el código o de lo contrario no se compilará?
Hamish Grubijan

2
El ORM no debe dictar los nombres de los objetos a los que se asignan. El punto de ORM es una abstracción del objeto, otorgando esta flexibilidad.
barrypicker

16
¡@HamishGrubijan luego deja de usar Word para escribir tu código! ;)
Valentino Vranken

37

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 .


33

Singular. No compro ningún argumento que sea más lógico: cada persona piensa que su propia preferencia es más lógica. No importa lo que hagas, es un desastre, solo elige una convención y cúmplela. Estamos tratando de mapear un lenguaje con gramática y semántica altamente irregulares (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.

Entonces, la AppUserrelación dice qué entidades son AppUsers.

La AppUserGrouprelación me dice qué entidades sonAppUserGroups

La AppUser_AppUserGrouprelación me dice cómo están relacionados el AppUsersy AppUserGroups.

La AppUserGroup_AppUserGrouprelación me dice cómo AppUserGroupsy AppUserGroupsestán relacionados (es decir, grupos miembros de grupos).

En otras palabras, cuando pienso en las entidades y cómo están relacionadas, pienso en las relaciones en singular, pero, por supuesto, cuando pienso en las 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 el plural para una mayor legibilidad, luego uso fuentes, etc. para distinguir el nombre de la tabla / relación del plural s.

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


1
exactamente. Lo principal que mucha gente no sabe aquí es lo que están nombrando ... está dando nombre a una relación (un único registro en la tabla), no al conjunto de registros en la tabla.
Alexandre Martini

3
No podría estar más en desacuerdo. 'Seleccione * de Usuarios donde Nombre como' J% '' porque estoy seleccionando a todos los usuarios donde el nombre comienza con 'J'. Si su argumento es que desea escribir '... donde User.Name como ...', simplemente use un alias. La misma razón por la que digo 'Dame un par de todos los calcetines disponibles'.
Mark A. Donohoe

Si fuera así de particular, el nombre de mi mesa sería sock_pair
Manuel Hernández

@AlexandreMartini Exactamente. Como algunas personas que llaman a un solo registro en la tabla "relación".
Nuno André

31

También iría con los plurales , y con el dilema de Usuarios antes mencionado , 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 Usuarios es una colección de valores de Usuario tanto como una colección de Usuarios en un artefacto de código es una colección de objetos de Usuario .

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


8
Estoy de acuerdo ... ¿por qué la inconsistencia entre el código y el almacenamiento? Nunca nombraría una colección de objetos de usuario "Usuario" en código ... entonces, ¿por qué llamaría a una tabla así? No tiene sentido. Cuando leo los argumentos anteriores al respecto, se centran en la entidad, no en la tabla ... hay una distinción entre lo que hay en la tabla y la tabla en mi mente.
Jason

¿Cómo manejas un nombre de tabla como companiesdonde otras tablas tienen un campo de referencia llamado company_id? Si bien está escrito correctamente, parece inconsistente para aquellos que son exigentes con las convenciones de nombres de tablas.
Jake Wilson

1
Al recordar que el singular de companieses company, y que esta identificación es una referencia a un elemento singular. No debería molestarnos en código más de lo que nos molesta en inglés.
David

22

Personalmente prefiero usar nombres en plural 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 a 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 todos los argumentos 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, intentaré servirles algo que les guste.


No es aconsejable utilizar dicha convención en el mundo del modelo relacional, especialmente cuando se describe la relación entre objetos, por ejemplo, "Cada equipo puede tener un solo entrenador principal y muchos entrenadores secundarios", que se describe: Equipo-> Entrenador principal, Equipo - >> SecondaryCoach
noonex

16

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

Utilizo ORM todo el tiempo, por supuesto, y ayuda que el código ORM escrito con nombres de tablas en plural se vea estúpido.


A cada uno lo suyo, supongo. Una tabla de base de datos relacional es, por definición, un encabezado (es decir, metadatos que nombran los atributos) y un conjunto de tuplas que coinciden con el encabezado. Puede centrarse en los metadatos, mientras que otras personas se centran en las tuplas. :-)
Bill Karwin el

¡Hola, User_Table es un nombre que me gusta! :)
Camilo Martin

3
El ORM no debe dictar los nombres de los objetos a los que se asignan. El punto de ORM es una abstracción del objeto, otorgando esta flexibilidad.
barrypicker

1
Lo veo de esta manera ... si creas una matriz / lista / diccionario de algo en el código, mi apuesta es que lo nombras con el nombre plural de lo que sea que contenga. Si está utilizando un ORM para abstraer su base de datos, las tablas se representan con algún tipo de colección, entonces, ¿por qué las trataría de manera diferente? Usar nombres singulares puede sonar bien, pero siempre está luchando contra su instinto de que una tabla contiene muchas de las mismas cosas, al igual que una colección de código. ¿Por qué la inconsistencia?
Jason

@ Jason: Por favor, comparar y contrastar la forma en que estas cosas leídas: 1) $db->user->row(27), $db->product->rows->where(something) 2) $db->users->row(27), $db->products->rows->where(something).
caos

16

En realidad, siempre pensé que era una convención popular usar nombres de tablas en plural. Hasta este punto, siempre he usado el plural.

Puedo entender el argumento para nombres de tablas singulares, pero para mí plural tiene más sentido. El nombre de una 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. Por lo tanto, la forma plural para el nombre de la tabla.

Una tabla de automóviles tendría el nombre de automóviles y cada fila es un automóvil. Admito que especificar la tabla junto con el campo de una table.fieldmanera es la mejor práctica 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, voy a repensar mi posición sobre el asunto, y confiaría en las convenciones reales utilizadas por la organización para la que me estoy desarrollando. Sin embargo, creo que para mis convenciones personales, me quedaré con los nombres de tablas en plural. Para mí tiene más sentido.


99
¿No es esta la convención en RoR también? ¿Nombres plurales para tablas y Singular para clases ORM? Tiene mucho sentido para mi. ¡La tabla se llama "carros" porque tiene muchas instancias de "car" y la clase se llama "Car" porque tendrá una instancia de un auto!
Sap

@Sap Una corrección menor de la última parte de la oración: la clase "Car" es un tipo de datos abstracto que representa un automóvil de la vida real. Si tendrá una instancia o múltiples depende de cómo se use.
pide el

Seamos realistas, la tabla cares una definición de la estructura de un solo automóvil. Si observa la estructura de la tabla, básicamente escupirá "id int, cadena de color, etc.": ¿digamos que tiene una tabla car_vendor(o para su versión plural sería cars_vendor) con la clave externa cars_id?! ¿Qué es esa estúpida mierda? No car_id hay necesidad de hacerme pensar. Singular es fuertemente preferido por mí
Toskan

44
¡Realmente me gusta esta respuesta! Dejame explicar. Si la colección es cary quieres todo lo carque es, blueel resultado debería ser algo así tire, mirror, engine. Y luego se está volviendo confuso porque todos los resultados son partsde a car. Entonces, el nombre de la tabla debe ser carparts(o car_parts, CarPartslo que quieras)
arnoudhgz

Cualquier diseñador de bases de datos que imponga nombres de tablas singulares básicamente declara la guerra contra cualquier desarrollador de aplicaciones de Ruby on Rails que pueda entrar en contacto con esa base de datos en el futuro. La estricta insistencia de Rail en palabras singulares para las clases y nombres en plural para las tablas, permite un comportamiento poderoso dentro de muchas gemas dentro del ecosistema de Ruby. Entonces, incluso si crees que el singular suena mejor, en aras de la compatibilidad, debes apegarte al plural. Me imagino que esto también es cierto para muchos otros Mapeadores Relacionales de Objetos.
Kelsey Hannan

15

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

Irónicamente, podría hacer Useruna excepción y llamarla Userspor USUARIO (Transac-SQL) , porque tampoco me gusta usar corchetes alrededor de las tablas si no tengo que hacerlo.

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

Todo esto se debe a que no tengo el debido respeto por los sistemas de bases de datos, solo estoy volviendo a aplicar el conocimiento de un truco de poni de las convenciones de nomenclatura OO como Java por costumbre y pereza. Desearía que hubiera un mejor soporte IDE para SQL complicado.


8
Nosotros, los chicos del plural, llamamos 'id' a la columna 'id' como tú, o 'singular_id'. Creo que las tablas deben ser plurales (piense en ellas como matrices), pero los nombres de columna deben ser singulares (atributos de un solo elemento).
mpen

plu_ral / PluRal para nombres de tablas, singular_id / singularId para claves primarias.
hochl

14

Ejecutamos estándares similares, cuando las secuencias de comandos exigimos [] alrededor de los nombres y, cuando corresponda, los calificadores de esquema, principalmente cubren sus apuestas contra 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 han corrido más de 10 años desde SQL 6.0 hasta SQL 2005, mucho más allá de su vida útil prevista.


Parece una autoflagelación ritualista. ¿Ya ha sucedido alguna de esas tomas de nombres?
Kjetil S.

13

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 enumeraría múltiples usuarios.

Esa es mi opinión de todos modos.


1
Más cerca de mi opinión, pero la mía es que el almacenamiento de la tabla de múltiples usuarios es realmente incidental, y que cualquier usuario singular está representado por la tabla, o más bien la relación que es un conjunto de tuplas que representan una entidad de Usuario.
ProfK

Creo que tiendo a estar de acuerdo con esto. Lo único que me confunde es por qué los modelos deberían ser singulares. Solo si el modelo solo se refiere a un solo Usuario. Si consultara la base de datos para obtener todos los usuarios, ¿tendría que acceder al modelo? No tiene sentido que una instancia singular obtenga todos los registros, por ejemplo: $ user-> get_all () // no tiene sentido
PM7Temp

12

Soy fanático de los nombres de tablas singulares, ya que hacen que mis diagramas ER usando la sintaxis CASE sean más fáciles de leer, pero al leer estas respuestas, ¿tengo la sensación de que nunca se entendió muy bien? Yo personalmente lo amo. Hay una buena descripción general con ejemplos de cuán legibles pueden ser sus modelos cuando usa nombres de tablas singulares, agrega verbos de acción a sus relaciones y forma buenas oraciones para cada relación. Es todo 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 a prefijar tablas y vistas, odio absolutamente esa práctica. No proporcione a una persona ninguna información antes de darle información posiblemente mala. Cualquier persona que busque objetos en una 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 dos tablas en el futuro, con una vista que las 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 nombrada con un prefijo tbl que puede confundir a algunos desarrolladores u obligar a reescribir otra capa, ya sea de nivel medio o de aplicación, para hacer referencia a mi nueva estructura o nombre viewUsers. Eso niega una gran parte del valor de las vistas en mi humilde opinión.


1
¡Buen ejemplo de una trampa de prefijar nombres de objetos con un calificador de 'tipo'!
Kenny Evitt

12

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


Microsoft son lo que son por razones comerciales primero (y a menudo razones poco éticas), las razones lógicas duran. Mi única razón para seguirlos es que son el gran gorila y todos los demás van por ese camino. Cuando tengo una opción, elijo lo contrario.
Bruce Patin

1
Cabe señalar que information_schemaes parte de ISO / IEC 9075-11, el estándar SQL. Y sí, usa nombres de tablas / vistas en plural.
Paulo Freitas

10

Si miramos 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 tabla definidos por el usuario. Eso no tiene mucho sentido que recomienden una cosa y sigan otra. Que los arquitectos de estos dos gigantes del software hayan nombrado sus tablas usando diferentes convenciones tampoco tiene mucho sentido ... Después de todo, ¿qué son estos tipos ... doctorados?

Sí 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 particular ...?


1
Microsoft son lo que son por razones comerciales primero (y a menudo razones poco éticas), las razones lógicas duran. Mi única razón para seguirlos es que son el gran gorila y todos los demás van por ese camino. Cuando tengo una opción, elijo lo contrario.
Bruce Patin

Dos cosas. Uno, normalmente no usaría los nombres de las tablas y escribiría 'select ID FROM OrderHeaders WHERE Reference =' ABC123 'porque está' Seleccionando todas las IDs de OrderHeaders donde algo es verdadero 'pero si tuviera que usar nombres de tablas debido a un unirse o lo que sea, usaría un alias así ... 'seleccione OrderHeader.ID FROM OrderHeaders como OrderHeader WHERE OrderHeader.Reference =' ABC123 '
Mark A. Donohoe

9

Esto puede ser un poco redundante, pero sugeriría ser cauteloso. No necesariamente es 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 sea muy mala :): sugeriría que la coherencia sea un objetivo mejor 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 hacia ese fin, sospecho que los nombres de las tablas son solo la punta del iceberg y que puede concentrarse en la tarea en cuestión, soportar el dolor de los objetos mal nombrados. tu mejor interés

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

my2cents ---


9

Posibles alternativas:

  • Cambiar el nombre de la tabla SystemUser
  • Use paréntesis
  • Mantenga los nombres de la tabla plural.

La OMI usando paréntesis es técnicamente el enfoque más seguro, aunque es un poco engorroso. En mi opinión, es 6 de uno, media docena del otro, y su solución realmente se reduce a las preferencias personales / de equipo.


2
Me gusta tu idea de 'prefijo', pero lo llamaría SystemUser.
ProfK

9

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

Ejemplo: una tabla de "colegios" puede contener 0 o más colegios, una tabla de "colegios" puede contener 0 o más colegios

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

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


8

Como otros han mencionado aquí, las convenciones deberían 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 proviene de mi experiencia en programación. Los nombres de clase son generalmente singulares a menos que sean algún tipo de colección. En mi opinión, estoy almacenando o leyendo registros individuales en la tabla en cuestión, por lo que singular tiene sentido para mí.

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

Intento evitar palabras reservadas en los nombres de mi tabla y columna, también. En el caso en cuestión aquí, tiene más sentido ir en contra de la convención singular para que los Usuarios eviten la necesidad de encapsular una tabla que usa la palabra reservada de Usuario.

Me gusta usar prefijos de manera limitada (tbl para nombres de tabla, sp_ para nombres de proceso, 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 las pautas de las convenciones de nombres: 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 existe un "Anillo único para gobernarlos a todos" cuando se trata de nombrar convenciones.


18
Ignorando los horrores de la notación húngara. Nunca, nunca, nunca use sp_ delante de los procedimientos almacenados porque MS-SQL lo usa para los procedimientos almacenados del sistema y los trata de manera especial. Dado que sp_ se almacenan en la tabla maestra, MS-SQL siempre se ve primero, incluso si califica la ubicación.
Will Dieterich

8

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 estoy inclinando a favor del singular en este momento debido a las irregularidades plurales en inglés. En alemán es aún peor debido a la ausencia de formas plurales consistentes: a veces no se puede saber si una palabra es plural o no sin el artículo que lo especifica (der / die / das). Y en los idiomas chinos no hay formas plurales de todos modos.


En la universidad me enseñan plurales para tablas, también tengo un libro aquí, gestión de DB tercera edición de los años 90, las tablas son singulares; mientras que también tengo una copia actualizada, 11e, nombres singulares y algunos abreviados, mientras que la sección XML usa plural. \ n Pero si verifica el contenido real de las secciones RDBMS, literalmente sigue siendo el mismo texto con algunas imágenes que han recibido un estiramiento facial. \ n La "lista de verificación de modelado de datos" no dice nada en plural o singular, solo que las entidades solo deberían mapearse a un solo objeto, eso es probablemente lo que intentaban imponer en los libros.
Marco

8

Una vez utilicé "Amigo" para la tabla Usuario: el mismo número reducido de caracteres, sin conflictos con las palabras clave, aún una referencia a un humano genérico. Si no me preocuparan las cabezas congestionadas que pudieran ver el código, lo habría mantenido así.


8

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 corta. Agregar una 's' al final de cada nombre de tabla me parece tan inútil como agregar 'tbl_' delante de cada una.


7

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 facilita a los generadores de código ORM producir clases de objetos y colecciones, ya que es más fácil producir un nombre plural a partir de un nombre singular que viceversa)


11
Esta convención ha sido parte de la teoría relacional mucho, mucho antes de que ORM existiera.
ProfK

1
El ORM no debe dictar los nombres de los objetos a los que se asignan. El punto de ORM es una abstracción del objeto, otorgando esta flexibilidad.
barrypicker

7

Solo uso sustantivos para los nombres de mi tabla que se escriben igual, ya sea singular o plural:

alce pez ciervo aeronave pantalones pantalones cortos anteojos tijeras especie descendencia


6

No vi esto claramente articulado en ninguna de las respuestas anteriores. Muchos programadores no tienen una definición formal en mente cuando trabajan con tablas. A menudo nos comunicamos intuitivamente en términos de "registros" o "filas". Sin embargo, con algunas excepciones para las relaciones desnormalizadas, las tablas generalmente se diseñan de modo que la relación entre los atributos no clave y la clave constituya una función teórica establecida.

Una función se puede definir como un subconjunto de un producto cruzado entre dos conjuntos, en el que cada elemento del conjunto de claves se produce como máximo una vez en la asignación. Por lo tanto, la terminología que surge de esa perspectiva tiende a ser singular. Uno ve la misma convención singular (o al menos no plural) en otras teorías matemáticas y computacionales que involucran funciones (álgebra y cálculo lambda, por ejemplo).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.