Práctica recomendada: ¿la mejor convención de nomenclatura de bases de datos para JPA?

Question

En Java la convención de nomenclatura para las propiedades baño clases (entidades) se hacen del CamelCase manera:

@Entity 
public class UserMessage implements Serializable { 
    @Id 
    private Integer id; 
    private String shortTitle; 
    private String longTitle; 
    private String htmlMessage; 
} 

Pero en el mundo de SQL se considera una best practice usar mayúsculas con guiones entre las palabras (como constantes de Java). En el mundo de SQL también se considera una práctica recomendada incluir el nombre de la tabla en los nombres de las columnas, de esta manera las claves externas se denominan en la mayoría de los casos exactamente igual que el ID en la tabla original.

CREATE TABLE USER_MESSAGE (
    USER_MESSAGE_ID MEDIUMINT(8) NOT NULL, 
    USER_MESSAGE_SHORT_TITLE VARCHAR(20), 
    USER_MESSAGE_LONG_TITLE VARCHAR(80), 
    USER_MESSAGE_HTML_MESSAGE TEXT NOT NULL 
); 

¿Debo seguir ambos estándares y usar el atributo de nombre en @Table y @Column? O debería seguir las convenciones de Java y confiar en las asignaciones de JPA predeterminadas.

¿Cuál es el enfoque más común y/o el mejor enfoque en este conflicto de normas?

Answer 1

¿Debo seguir ambos estándares y usar el atributo de nombre en @Table y @Column? O debería seguir las convenciones de Java y confiar en las asignaciones de JPA predeterminadas.

Si las convenciones de la APP por defecto no coinciden con los preferidos convenciones de su empresa (no hay un "verdadero" estándar), anularlos. Esto se puede hacer usando las anotaciones @Table y @Column (en el caso particular de Hibernate, también podría proporcionar su propio implementation of a NamingStrategy).

¿Cuál es el enfoque más común y/o el mejor enfoque en este conflicto de normas?

No hay conflicto, hay convenciones de nombres de Java, hay una convención por defecto en el lado de la APP para el mapeo de objetos a tablas (porque APP tenía que elegir uno) y no hay "una verdadero "estándar en el lado SQL. Por lo tanto:

• si su empresa no tiene ningún convenciones de nomenclatura de SQL, puede utilizar las convenciones de la APP
  • si no les gustan, anularlos
• si su empresa convenciones en su lugar, síguelos y anule los valores predeterminados de JPA

Answer 2

Seguir a los dos. La convención de db debería estar ahí para el motivo de DBA y los informes manuales y las consultas donde el conjunto de ideas es diferente. Use los parametros del nombre en las anotaciones para lograr esto.

Answer 3

Supongo que esto depende de a qué convenciones se refiere. No pongo el nombre de la tabla en el nombre de la columna. ¿De qué sirve perder la mitad de tu espacio de nombres solo para repetir lo que ya sabes? (Algunas de) las reglas que (intento) seguir son:

1. Los nombres largos y significativos son mejores que los nombres cortos, p. TRANSACTION_DATE en lugar de TRAN_DT. Sí, tengo edad suficiente para haber escrito Fortran cuando estaba limitado a nombres de variables de 6 caracteres, y recuerdo variantes básicas en las que solo tenía AZ, A0-Z0 ... A9-Z9, pero también tengo edad suficiente haber aprendido mejor Los nombres de variable de un solo carácter para índices, etc., están bien, y de hecho son tradicionales, pero cuando encuentro una función con doce nombres de variable de una letra, cada uno de los cuales se usa para múltiples propósitos, ... no me divierte.

2. Las claves primarias artificiales se llaman ID_ < < "name of table" >>.

3. Las claves primarias de datos naturales de campo único son las mejores. Las claves primarias naturales de dos campos están bien. Tres o más campos: crea una clave primaria artificial y convierte la clave natural en una clave única alternativa.

4. Nunca, nunca, nunca contará con una fecha, hora o campo de fecha/hora para ser único. Nunca. No olvide esto Lo digo en serio.

5. Las técnicas de codificación ofuscadoras son equivalentes a la incompetencia.

Estoy seguro de que hay más, pero es un comienzo. Todo en mi humilde opinión. YMMV.

Comparte y disfruta.

Answer 4

Por lo que a mí respecta, cualquiera de ellos es aceptable. Pero si decide que no desea la carcasa de camello predeterminada, PUEDE obtener una estrategia de nombres diferente sin recurrir a la tarea tediosa y propensa a errores de agregar el atributo de nombre a cada anotación.

Eche un vistazo a la clase org.hibernate.cfg.ImprovedNamingStrategy de Hibernate. Utiliza guiones bajos en lugar de caja de camello. Es simplemente una cuestión de establecer una propiedad en su configuración de Hibernate para usarla.

También puede extender la estrategia de nombres mejorados para anteponer el nombre de la tabla o hacer todo en mayúsculas si realmente lo desea, pero eso parece innecesario.