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

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?

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

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]

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.

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.

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

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

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.

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.

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 .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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"

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.

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.

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

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.

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)

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

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