Estoy comenzando un nuevo proyecto y me gustaría obtener mis nombres de tabla y columna desde el principio. Por ejemplo, siempre he usado el plural en los nombres de las tablas, pero recientemente aprendí que el singular es correcto.

Entonces, si obtuve una tabla "usuario" y luego obtuve productos que solo el usuario tendrá, ¿la tabla debería llamarse "usuario_producto" o simplemente "producto"? Esta es una relación de uno a muchos.

Y más adelante, si tuviera (por alguna razón) varias descripciones de productos para cada producto, ¿sería "user_product_description" o "product_description" o simplemente "description"? Por supuesto, con las claves foráneas correctas establecidas. Nombrar solo la descripción sería problemático ya que también podría tener una descripción de usuario o una descripción de cuenta o lo que sea ...

¿Qué pasa si quiero una tabla relacional pura (muchas a muchas) con solo dos columnas, ¿cómo sería? "user_stuff" o tal vez algo como "rel_user_stuff"? Y si el primero, ¿qué distinguiría esto de, por ejemplo, "user_product"?

Cualquier ayuda es muy apreciada y si hay algún tipo de convención de nomenclatura estándar que ustedes recomienden, no duden en vincular.

Gracias

Nombre de la tabla

recientemente aprendido singular es correcto

Si. Cuidado con los paganos. Plural en los nombres de las tablas. son un signo seguro de alguien que no ha leído ninguno de los materiales estándar y no tiene conocimiento de la teoría de bases de datos.

Algunas de las cosas maravillosas sobre los estándares son:

• todos están integrados entre sí
• trabajan juntos
• fueron escritos por mentes más grandes que la nuestra, por lo que no tenemos que debatirlos.

El nombre de la tabla estándar se refiere a cada fila de la tabla, que se usa en todos los verbos, no el contenido total de la tabla (sabemos que la Customertabla contiene todos los Clientes).

Relación, frase verbal

En las bases de datos relacionales genuinas que se han modelado (a diferencia de los sistemas de archivo de registros anteriores a 1970 [caracterizados porque Record IDsse implementan en un contenedor de base de datos SQL por conveniencia):

• las tablas son los Sujetos de la base de datos, por lo tanto son sustantivos , nuevamente, singulares
• las relaciones entre las tablas son las acciones que tienen lugar entre los sustantivos, por lo tanto, son verbos (es decir, no están numerados ni nombrados arbitrariamente)
• ese es el predicado
• todo lo que se puede leer directamente del modelo de datos (consulte mis ejemplos al final)
• (el predicado para una tabla independiente (el principal superior en una jerarquía) es que es independiente)
• así, la Frase verbal se elige cuidadosamente, de modo que sea la más significativa, y se evitan los términos genéricos (esto se hace más fácil con la experiencia). La frase verbal es importante durante el modelado porque ayuda a resolver el modelo, es decir. aclarando relaciones, identificando errores y corrigiendo los nombres de las tablas.

Diagrama_A

Por supuesto, la relación se implementa en SQL como CONSTRAINT FOREIGN KEYen la tabla secundaria (más, más adelante). Aquí está la frase verbal (en el modelo), el predicado que representa (para leer del modelo) y el nombre de restricción FK :

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Tabla • Idioma

Sin embargo, cuando describa la tabla, particularmente en lenguaje técnico como los predicados u otra documentación, use el singular y el plural tal como están en el idioma inglés. Teniendo en cuenta que la tabla se nombra para la fila única (relación) y el lenguaje se refiere a cada fila derivada (relación derivada):

    Each Customer initiates zero-to-many SalesOrders

no

    Customers have zero-to-many SalesOrders 

Entonces, si obtuve una tabla "usuario" y luego obtuve productos que solo el usuario tendrá, ¿la tabla debería llamarse "usuario-producto" o simplemente "producto"? Esta es una relación de uno a muchos.

(Esa no es una pregunta de convención de nomenclatura; esa es una pregunta de diseño de db.) No importa si user::productes 1 :: n. Lo que importa es si productes una entidad separada y si es una tabla independiente , es decir. Puede existir por sí mismo. Por lo tanto productno user_product.

Y si productexiste solo en el contexto de un user, es decir. es una tabla dependiente , por lo tanto user_product.

Diagrama_B

Y más adelante, si tuviera (por alguna razón) varias descripciones de productos para cada producto, ¿sería "descripción de producto de usuario" o "descripción de producto" o simplemente "descripción"? Por supuesto, con las claves foráneas correctas establecidas. Nombrar solo la descripción sería problemático ya que también podría tener una descripción de usuario o una descripción de cuenta o lo que sea.

Así es. De cualquier user_product_descriptionXOR product_descriptionserá correcta, sobre la base de lo anterior. No es para diferenciarlo de otro xxxx_descriptions, sino para darle al nombre una idea de dónde pertenece, siendo el prefijo la tabla principal.

¿Qué pasa si quiero una tabla relacional pura (muchas a muchas) con solo dos columnas, ¿cómo sería? "user-stuff" o tal vez algo como "rel-user-stuff"? Y si es el primero, ¿qué distinguiría esto de, por ejemplo, "producto de usuario"?

1. Afortunadamente, todas las tablas en la base de datos relacional son tablas puramente relacionales y normalizadas. No es necesario identificar eso en el nombre (de lo contrario, todas las tablas estarán rel_something).

2. Si contiene solo las PK de los dos padres (que resuelve la relación lógica n :: n que no existe como entidad en el nivel lógico, en una tabla física ), esa es una Tabla asociativa . Sí, normalmente el nombre es una combinación de los dos nombres de la tabla principal.

   • Tenga en cuenta que en estos casos la Frase verbal se aplica y se lee de padres a padres, ignorando la tabla secundaria, porque su único propósito en la vida es relacionar a los dos padres.

     Diagrama_C

   • Si es no una tabla asociativa (es decir., Además de los dos PKs, contiene datos), a continuación, nombre apropiadamente, y las frases verbales se aplican a la misma, no el padre al final de la relación.

     Diagrama_D

3. Si termina con dos user_producttablas, es una señal muy fuerte de que no ha normalizado los datos. Así que retroceda unos pasos y haga eso, y nombre las tablas con precisión y coherencia. Los nombres se resolverán por sí mismos.

Convenio de denominación

Cualquier ayuda es muy apreciada y si hay algún tipo de convención de nomenclatura estándar que ustedes recomienden, no duden en vincular.

Lo que está haciendo es muy importante y afectará la facilidad de uso y comprensión en todos los niveles. Por lo tanto, es bueno obtener la mayor comprensión posible desde el principio. La relevancia de la mayoría de esto no será clara, hasta que comience a codificar en SQL.

1. El caso es el primer elemento a tratar. Todas las mayúsculas son inaceptables. El caso mixto es normal, especialmente si los usuarios pueden acceder directamente a las tablas. Consulte mis modelos de datos. Tenga en cuenta que cuando el buscador está utilizando un NonSQL demente, que solo tiene minúsculas, le doy eso, en cuyo caso incluyo guiones bajos (según sus ejemplos).

2. Mantener un enfoque de datos , no una aplicación o enfoque de uso. Es, después de todo 2011, hemos tenido Arquitectura Abierta desde 1984, y se supone que las bases de datos son independientes de las aplicaciones que las usan.

   De esa manera, a medida que crecen, y más de lo que las usa una aplicación, los nombres seguirán siendo significativos y no necesitarán corrección. (Las bases de datos que están completamente integradas en una sola aplicación no son bases de datos). Nombra los elementos de datos solo como datos.

3. Sea muy considerado y nombre las tablas y columnas con mucha precisión . No lo use UpdatedDatesi es un DATETIMEtipo de datos, úselo UpdatedDtm. No lo use _descriptionsi contiene una dosis.

4. Es importante ser coherente en toda la base de datos. No lo use NumProducten un lugar para indicar la cantidad de Productos ItemNoni ItemNumen otro lugar para indicar la cantidad de Artículos. Úselo NumSomethingpara números de, y / SomethingNoo SomethingIdpara identificadores, consistentemente.

5. No prefije el nombre de la columna con un nombre de tabla o código corto, como user_first_name. SQL ya proporciona el nombre de la tabla como calificador:

       table_name.column_name  -- notice the dot
   

6. Excepciones:

   • La primera excepción es para las PK, necesitan un manejo especial porque las codifica en combinaciones todo el tiempo y desea que las claves se destaquen de las columnas de datos. Siempre use user_id, nunca id.

     • Tenga en cuenta que este no es un nombre de tabla utilizado como prefijo, sino un nombre descriptivo adecuado para el componente de la clave: user_ides la columna que identifica a un usuario, no el nombre iddeluser tabla.
       • (Excepto, por supuesto, en los sistemas de archivo de registros, donde los sustitutos acceden a los archivos y no hay claves relacionales, allí son una y la misma cosa).
     • Utilice siempre el mismo nombre exacto para la columna de clave dondequiera que se transporte (migre) la PK como FK.
     • Por lo tanto, la user_producttabla tendrá user_idun componente de su PK (user_id, product_no).
     • La relevancia de esto quedará clara cuando comience a codificar. Primero, con idmuchas tablas, es fácil confundirse en la codificación SQL. En segundo lugar, cualquier otra persona que el codificador inicial no tiene idea de lo que estaba tratando de hacer. Ambos son fáciles de evitar, si las columnas clave se tratan como anteriormente.

   • La segunda excepción es cuando hay más de un FK que hace referencia a la misma tabla de la tabla principal, que se lleva en el elemento secundario. Según el modelo relacional , use nombres de roles para diferenciar el significado o uso, por ejemplo. AssemblyCodey ComponentCodepara dos PartCodes. Y en ese caso, no use el indiferenciado PartCodepara uno de ellos. Se preciso.

     Diagrama_E

7. Prefijo
   Cuando tenga más de 100 tablas, prefije los nombres de las tablas con un Área temática:

   REF_ para tablas de referencia
   OE_ para el clúster de entrada de pedidos, etc.

   Solo a nivel físico, no lógico (desordena el modelo).

8. Sufijo
   Nunca use sufijos en las tablas, y siempre use sufijos en todo lo demás. Eso significa que en el uso lógico y normal de la base de datos, no hay guiones bajos; pero en el aspecto administrativo, los guiones bajos se usan como separador:

   _VVer (con el principal TableNameal frente, por supuesto)
   _fkClave externa (el nombre de la restricción, no el nombre de la columna) Transacción de segmento de
   _caccaché (proceso almacenado o función) Función (no transaccional), etc.
   _seg
_tr
_fn

   El formato es el nombre de la tabla o FK, un guión bajo y el nombre de la acción, un guión bajo y, finalmente, el sufijo.

   Esto es realmente importante porque cuando el servidor te da un mensaje de error:

   ____blah blah blah error on object_name

   sabes exactamente qué objeto se violó y qué estaba tratando de hacer:

   ____blah blah blah error on Customer_Add_tr

9. Claves foráneas (la restricción, no la columna). El mejor nombre para un FK es usar la frase verbal (menos el "cada" y la cardinalidad).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   Use la Parent_Child_fksecuencia, no Child_Parent_fkes porque (a) se muestra en el orden correcto cuando los está buscando y (b) siempre conocemos al niño involucrado, lo que estamos adivinando es qué padre. El mensaje de error es entonces encantador:

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Eso funciona bien para las personas que se molestan en modelar sus datos, donde se han identificado las frases verbales. Por lo demás, los sistemas de archivo de registro, etc, el uso Parent_Child_fk.

10. Los índices son especiales, por lo que tienen una convención de nomenclatura propia, compuesta, en orden , por cada posición de personaje del 1 al 3:

    UÚnico, o _para no único
    Cen clúster, o _para no agrupado
    _ separador

    Para el resto:

    • Si la clave es una columna o muy pocas columnas:
      ____ColumnNames

    • Si la clave tiene más de unas pocas columnas:
      ____ PKClave primaria (según el modelo)
      ____ AK[*n*]Clave alternativa (término IDEF1X)

    Tenga en cuenta que el nombre de la tabla no es obligatorio en el nombre del índice, ya que siempre aparece comotable_name.index_name.

    Entonces, cuando Customer.UC_CustomerIdo Product.U__AKaparece en un mensaje de error, le dice algo significativo. Cuando observa los índices en una tabla, puede diferenciarlos fácilmente.

11. Encuentre a alguien calificado y profesional y sígalos. Mire sus diseños y estudie cuidadosamente las convenciones de nombres que usan. Hágales preguntas específicas sobre cualquier cosa que no entienda. Por el contrario, huye de cualquiera que demuestre poco respeto por las convenciones o estándares de nombres. Aquí hay algunos para comenzar:

    • Contienen ejemplos reales de todo lo anterior. Haga preguntas para cambiar el nombre de las preguntas en este hilo.
    • Por supuesto, los modelos implementan varios otros estándares, más allá de las convenciones de nombres; puede ignorarlos por ahora o no dude en hacer nuevas preguntas específicas .
    • Son varias páginas cada una, el soporte de imágenes en línea en Stack Overflow es para las aves, y no se cargan constantemente en diferentes navegadores; así que tendrás que hacer clic en los enlaces.
    • Tenga en cuenta que los archivos PDF tienen navegación completa, así que haga clic en los botones de cristal azul o en los objetos donde se identifica la expansión:
    • Los lectores que no estén familiarizados con el Estándar de modelado relacional pueden encontrar útil la notación IDEF1X .

Ingreso de pedidos e inventario con direcciones que cumplen con los estándares

Sistema simple de boletines entre oficinas para PHP / MyNonSQL

Monitoreo de sensores con capacidad temporal completa

Respuestas a preguntas

^{Eso no se puede responder razonablemente en el espacio de comentarios.}

Larry Lustig:
... incluso el ejemplo más trivial muestra ...
Si un Cliente tiene Productos de cero a muchos y un Producto tiene Componentes de uno a muchos y un Componente tiene Proveedores de uno a muchos y un Proveedor vende cero Componentes para muchos y un SalesRep tiene Clientes uno a muchos ¿Cuáles son los nombres "naturales" de las tablas que contienen Clientes, Productos, Componentes y Proveedores?

Hay dos problemas principales en su comentario:

1. Declaras que tu ejemplo es "el más trivial", sin embargo, es todo lo contrario. Con ese tipo de contradicción, no estoy seguro de si usted es serio, si técnicamente capaz.

2. Esa especulación "trivial" tiene varios errores graves de normalización (diseño de base de datos).

   • Hasta que los corrija, no son naturales ni anormales, y no tienen ningún sentido. También podría nombrarlos anormal_1, anormal_2, etc.

   • Tienes "proveedores" que no suministran nada; referencias circulares (ilegales e innecesarias); clientes que compran productos sin ningún instrumento comercial (como Factura o Pedido de ventas) como base para la compra (¿o los clientes "poseen" productos?); relaciones de muchos a muchos sin resolver; etc.

   • Una vez que se normalice, y se identifiquen las tablas requeridas, sus nombres serán obvios. Naturalmente.

En cualquier caso, intentaré atender su consulta. Lo que significa que tendré que darle un poco de sentido, sin saber lo que querías decir, así que ten paciencia conmigo. Los errores graves son demasiados para enumerarlos, y dada la especificación adicional, no estoy seguro de haberlos corregido todos.

• Asumiré que si el producto está compuesto de componentes, entonces el producto es un ensamblaje y los componentes se usan en más de un ensamblaje.

• Además, dado que el "Proveedor vende componentes de cero a muchos", que no venden productos o ensamblajes, solo venden componentes.

Especulación vs modelo normalizado

En caso de que no lo sepa, la diferencia entre las esquinas cuadradas (Independiente) y las esquinas redondeadas (Dependiente) es significativa, consulte el enlace de notación IDEF1X. Del mismo modo, las líneas continuas (de identificación) frente a las líneas discontinuas (no identificables).

... ¿cuáles son los nombres "naturales" de las tablas que contienen clientes, productos, componentes y proveedores?

• Cliente
• Producto
• Componente (o Componente de ensamblaje, para aquellos que se dan cuenta de que un hecho identifica al otro)
• Proveedor

Ahora que he resuelto las tablas, no entiendo tu problema. Quizás puedas publicar una pregunta específica .

VoteCoffee:
¿Cómo maneja el escenario que Ronnis publicó en su ejemplo donde existen múltiples relaciones entre 2 tablas (user_likes_product, user_bought_product)? Puedo entender mal, pero esto parece dar como resultado nombres de tablas duplicados utilizando la convención que detalló.

Asumiendo que no hay errores de Normalización, User likes Productes un predicado, no una tabla. No los confundas. Consulte mi Respuesta, donde se relaciona con Sujetos, Verbos y Predicados, y mi respuesta a Larry inmediatamente arriba.

• Cada tabla contiene un conjunto de hechos (cada fila es un hecho). Los predicados (o proposiciones) no son hechos, pueden o no ser ciertos.

  • El modelo relacional se basa en el cálculo de predicados de primer orden (más comúnmente conocido como lógica de primer orden). Un predicado es una oración de una sola cláusula en inglés simple y preciso, que se evalúa como verdadero o falso.

  • Además, cada tabla representa, o es la implementación de, muchos predicados, no uno.

• Una consulta es una prueba de un predicado (o varios predicados, encadenados) que da como resultado verdadero (el hecho existe) o falso (el hecho no existe).

• Por lo tanto, las tablas deben nombrarse, como se detalla en mi Respuesta (convenciones de nomenclatura), para la fila, el Hecho y los Predicados deben documentarse (por supuesto, es parte de la documentación de la base de datos), pero como una lista separada de Predicados .

• Esto no es una sugerencia de que no son importantes. Son muy importantes, pero no escribiré eso aquí.

• Rápidamente, entonces. Dado que el Modelo Relacional se basa en FOPC, se puede decir que toda la base de datos es un conjunto de declaraciones de FOPC, un conjunto de Predicados. Pero (a) hay muchos tipos de Predicados, y (b) una tabla no representa un Predicado (es la implementación física de muchos Predicados y de diferentes tipos de Predicados).

• Por lo tanto, nombrar la tabla para "el" Predicar que "representa" es un concepto absurdo.

• Los "teóricos" conocen solo unos pocos predicados, no entienden que desde que el RM se fundó en el FOL, toda la base de datos es un conjunto de predicados y de diferentes tipos.

  • Y, por supuesto, que elijan los absurdos de los pocos que sí saben: EXISTING_PERSON; PERSON_IS_CALLED. Si no fuera tan triste, sería muy gracioso.

  • Tenga en cuenta también que el nombre de la tabla estándar o atómica (nombrando la fila) funciona de manera brillante para todo el verborrea (incluidos todos los predicados adjuntos a la tabla). Por el contrario, el nombre idiota de "tabla representa predicado" no puede. Lo cual está bien para los "teóricos", que entienden muy poco acerca de los predicados, pero retrasados ​​de lo contrario.

• Los predicados que son relevantes para el modelo de datos, se expresan en el modelo, son de dos órdenes.

  1. Predicado unario
     El primer conjunto es esquemático , no texto: la notación en sí . Estos incluyen varios existenciales; Orientado a la restricción; y predicadores descriptores (atributos).

     • Por supuesto, eso significa que solo aquellos que pueden 'leer' un modelo de datos estándar pueden leer esos predicados. Es por eso que los "teóricos", que están severamente paralizados por su mentalidad de solo texto, no pueden leer modelos de datos, por qué se apegan a su mentalidad de solo texto anterior a 1984.

  2. Predicado binario
     El segundo conjunto son aquellos que forman relaciones entre hechos. Esta es la línea de relación. La frase verbal (detallada anteriormente) identifica el predicado, la proposición , que se ha implementado (que se puede probar mediante una consulta). Uno no puede ser más explícito que eso.

     • Por lo tanto, para quien domina los modelos de datos estándar, todos los predicados relevantes son documentados en el modelo. No necesitan una lista separada de Predicados (¡pero los usuarios, que no pueden 'leer' todo del modelo de datos, lo hacen!).

• Aquí hay un modelo de datos , donde he enumerado los predicados. He elegido ese ejemplo porque muestra los predicados existenciales, etc., así como los de relación, los únicos predicados no enumerados son los descriptores. Aquí, debido al nivel de aprendizaje del buscador, lo estoy tratando como un usuario.

Por lo tanto, el evento de más de una tabla secundaria entre dos tablas primarias no es un problema, solo nómbrelas como el hecho existencial en relación con su contenido y normalice los nombres.

Aquí entran en juego las reglas que di para las frases verbales para nombres de relaciones para tablas asociativas. Aquí hay una discusión de Predicate vs Table , que cubre todos los puntos mencionados, en resumen.

Para una buena descripción breve sobre el uso adecuado de los predicados y cómo usarlos (que es un contexto bastante diferente al de responder a los comentarios aquí), visite esta respuesta y desplácese hacia abajo a la sección de predicados .

Charles Burns:
Por secuencia, me refería al objeto de estilo Oracle utilizado exclusivamente para almacenar un número y su siguiente según alguna regla (por ejemplo, "agregar 1"). Como Oracle carece de tablas de identificación automática, mi uso típico es generar identificaciones únicas para las PK de tabla. INSERTAR EN LOS VALORES foo (id, somedata) (foo_s.nextval, "data" ...)

Ok, eso es lo que llamamos una tabla Key o NextKey. Nómbralo como tal. Si tiene SubjectAreas, use COM_NextKey para indicar que es común en la base de datos.

Por cierto, ese es un método muy pobre para generar claves. No es escalable en absoluto, pero luego, con el rendimiento de Oracle, probablemente esté "bien". Además, indica que su base de datos está llena de sustitutos, no relacionales en esas áreas. Lo que significa un rendimiento extremadamente pobre y falta de integridad.

Singular vs. Plural: elige uno y quédate con él.

Las columnas no deben tener el prefijo / sufijo / infijo o de todos modos fijados con referencias al hecho de que es una columna. Lo mismo vale para las mesas. No nombre las tablas EMPLOYEE_T o TBL_EMPLOYEES porque en el segundo que se reemplaza con una vista, las cosas se vuelven realmente confusas.

No inserte información de tipo en nombres, como "vc_firstname" para varchar o "flavour_enum". Tampoco incruste restricciones en los nombres de columna, como "department_fk" o "employee_pk".

En realidad, la única cosa buena acerca de las correcciones * se me ocurre, es que se puede utilizar como palabras reservadas where_t, tbl_order, user_vw. Por supuesto, en esos ejemplos, el uso del plural habría resuelto el problema :)

No nombre todas las claves "ID". Las claves que se refieren a la misma cosa, deben tener el mismo nombre en todas las tablas. La columna de ID de usuario podría llamarse USER_ID en la tabla de usuario y todas las tablas que hacen referencia al usuario. El único momento en que cambia su nombre es cuando diferentes usuarios desempeñan diferentes roles, como Mensaje (sender_user_id, receptor_usuario_id). Esto realmente ayuda cuando se trata de consultas más grandes.

Con respecto a CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

En general, es mejor nombrar "tablas de mapeo" para que coincidan con la relación que describe en lugar de los nombres de las tablas referenciadas. Un usuario puede tener cualquier número de relaciones con los productos user_likes_product, user_bought_product, user_wants_to_buy_product.

No hay "correcto" sobre singular versus plural: es principalmente una cuestión de gustos.

Depende en parte de tu enfoque. Si piensa en la tabla como una unidad, contiene 'plurales' (porque contiene muchas filas, por lo que un nombre plural es apropiado). Si piensa que el nombre de la tabla identifica una fila en una tabla, preferirá 'singular'. Esto significa que se considerará que su SQL funciona en una fila de la tabla. Eso está bien, aunque generalmente es una simplificación excesiva; SQL funciona en conjuntos (más o menos). Sin embargo, podemos ir con singular para las respuestas a esta pregunta.

1. Como probablemente necesitará una tabla 'usuario', otro 'producto' y el tercero para conectar a los usuarios con los productos, necesitará una tabla 'usuario_producto'.

2. Como la descripción se aplica a un producto, usaría 'product_description'. A menos que cada usuario nombre cada producto por sí mismo ...

3. La tabla 'user_product' es (o podría ser) un ejemplo de una tabla con un ID de producto y un ID de usuario y no mucho más. Nombra las tablas de dos atributos de la misma manera general: 'user_stuff'. Los prefijos decorativos como 'rel_' realmente no ayudan. Verá algunas personas usando 't_' delante de cada nombre de tabla, por ejemplo. Eso no es de mucha ayuda.

Los plurales no son malos siempre que se usen de manera consistente, pero el singular es mi preferencia.

Prescindiría de los guiones bajos a menos que desee esbozar una relación de muchos a muchos; y use un capital inicial porque ayuda a distinguir cosas en ORM.

Pero hay muchas convenciones de nomenclatura, por lo que si desea utilizar guiones bajos, está bien siempre que se haga de forma coherente.

Entonces:

User

UserProduct (it is a users products after all)

Si solo un usuario puede tener algún producto, entonces

UserProductDescription

Pero si el producto es compartido por los usuarios:

ProductDescription

Si guarda sus guiones bajos para las relaciones de muchos a muchos, puede hacer algo como:

UserProduct_Stuff

para formar un M-to-M entre UserProduct y Stuff - no estoy seguro de la pregunta de la naturaleza exacta de los muchos a muchos requeridos.

No hay más correcto usar el singular que el plural, ¿dónde has escuchado eso? Prefiero decir que la forma plural es más común para nombrar tablas de bases de datos ... y, en mi opinión, también más lógica. La tabla suele contener más de una fila;) En un modelo conceptual, los nombres de las entidades suelen estar en singular.

Sobre su pregunta, si 'Producto' y 'Descripción del producto' son conceptos con una identidad (es decir, entidades) en su modelo, simplemente llamaría a las tablas 'Productos' y 'Descripción del producto'. Para las tablas que se usan para implementar una relación de muchos a muchos, a menudo uso la convención de nomenclatura "SideA2SideB", por ejemplo, "Student2Course".