Nombres de entidades frente a nombres de tablas

Question

Vamos a desarrollar un nuevo sistema sobre una base de datos heredada (usando .NET C#). Hay aproximadamente 500 tablas. Hemos elegido utilizar una herramienta ORM para nuestra capa de acceso a datos. El problema es con la convención namig para las entidades.

Las tablas en la base de datos tienen nombres como TB_CUST - tabla con datos del cliente, o TP_COMP_CARS - coches de empresa. La primera letra del prefijo define el módulo y la segunda letra define sus relaciones con otras tablas.

Me gustaría nombrar las entidades más significativas. Me gusta TB_CUST solo Customer o CustomerEntity. Por supuesto, habría un comentario que apunta a su nombre de tabla.

Pero el DBA y el programador en una sola persona, no quieren nombres como este. Él quiere que las entidades nombren exactamente lo mismo para los nombres de las tablas. Él está diciendo que tendría que recordar dos nombres y que sería difícil y complicado. Debo decir que no está muy familiarizado con los principios de OOP.

Pero en el caso de un nombre de entidad como TP_COMP_CARS debe haber nombres de métodos como Get TP_COMP_CARS o SaveTP_COMP_CARS .. Creo que esto es ilegible y feo.

Así que por favor dígame su opinión. ¿Quién tiene razón y por qué?

gracias de antemano

Answer 1

La idea de herramientas ORM, es evitar la necesidad de recordar los objetos de base de datos. Normalmente creamos una clase de base de datos con todos los nombres de tabla y columna, por lo que nadie necesita recordar nada, y el ORM debe asignar nombres de base de datos a entidades normales.

Aunque es subjetiva, en mi opinión tiene usted razón y él está mal ....

Answer 2

Quién se va a trabajar sobre todo con el nuevo código? Esa persona debe decidir la convención de nombres en mi humilde opinión.

Personalmente, por supuesto, iría por su solución porque, como ya se ha mencionado, si usa ORM no necesita acceder directamente a la base de datos.

Answer 3

Como compromiso, puede usar nombres como TB_CUST donde actúa directamente con la base de datos pero luego usa nombres como Cliente para sus objetos de transferencia de datos. Escribir un buen código implica crear una abstracción de cualquier fuente de datos con la que pueda estar trabajando. Tener GetTB_CUST() en todo su código es un poco como tener GetTB_CUSTFromThatSQLDatabaseWeHave() salpicado alrededor del lugar.

Answer 4

Las convenciones de nomenclatura utilizadas en dos dominios diferentes simplemente no se alinean. Java, por ejemplo, tiene reglas/convenciones muy definidas para nombres de clase y campo nombres, donde la capitalización es significativa. En general, su aplicación puede ser portada a una base de datos completamente diferente con un estándar de nomenclatura diferente, no es razonable exigir alineación de nombres en Business Logic con nombres en la base de datos. Considere un mapeo un poco más complejo, una entidad puede no corresponder a una tabla.

Y, en realidad, vamos ...

Customer == TB_CUST 

Eso simplemente no es tan difícil! Estoy contigo, hace que los nombres tengan sentido en el código y el mapa en el ORM.El aprendizaje para el DBA/Programador no debería ser tan doloroso, supongo que es una de esas cosas que se siente mucho peor en la anticipación que la realidad.

Answer 5

Personalmente odio los nombres de tablas así, pero es un sistema heredado y estoy seguro de que el DBA no tiene ganas de renombrar las tablas. Cambiar el nombre de las tablas podría ser una opción. Solo tendría que crear vistas que representen los nombres de tablas antiguas para que su sistema heredado siga funcionando mientras desarrolla su nuevo sistema. Si no se trata de una opción, puede usar el ORM para asignar los nombres de las tablas a los nombres de las entidades. O puede abstraer su ORM en una capa de acceso a datos y definir buenos nombres de entidad en su modelo de dominio, haciendo que su DAL haga la conversión del nombre.

Answer 6

"Tengo que decir que su no muy familiarizado con los principios de la programación orientada a objetos.

Pero en el caso de un nombre de entidad como TP_COMP_CARS debería haber nombres métodos como Get TP_COMP_CARS o SaveTP_COMP_CARS..I piensan que esto no se puede leer y feo

Así que díganme su opinión. ¿Quién tiene razón y por qué?

Los nombres que se asignan a las cosas que administran sus sistemas de TI no tienen absolutamente nada que ver con "los principios de OOP".

Lo mismo vale para los nombres dados a los métodos "estándar" "getter and setter": esos son solo acuerdos y convenciones, no "principios de OOP".

El problema es un cierto tipo de "ergonomía" (y por lo tanto también el valor de auto-documentación) del código.

Es cierto que getTP_COMP_CARS se ve feo (aunque no, como usted dice, "ilegible"). También es cierto que si comienzas a adherirte a las convenciones de nombres "más modernas", entonces tendrá que haber alguien en alguna parte que tenga que mantener un mapeo entre los nombres que son sinónimos. (Y es falso que nombres como TP_COMP_CARS sean menos autodocumentados que nombres completos de "palabras en lenguaje natural": generalmente dichos nombres se construyen a partir de un conjunto MUY PEQUEÑO de palabras mnemotécnicas que se usan una y otra vez con el mismo significado , por lo que es más que fácil de recordar para cualquiera.)

No hay nada de malo en esto. Los nombres como ese eran la convención habitual en los días anteriores a los que vivimos ahora. Al menos, esos nombres solían tener el beneficio de ser insensibles a las mayúsculas y minúsculas, a diferencia de las reglas de nomenclatura basadas en el cerebro (porque distinguen entre mayúsculas y minúsculas) que nos imponen los denominados sistemas "más modernos".

Veinte años a partir de ahora, la gente llamará a las convenciones de nomenclatura que usamos estos días "braindead" también.

Answer 7

Si hay 500 tablas en la base de datos, ya tiene un desafío para mantener esos nombres correctos. Con suerte, tienes metadatos y algunos modelos gráficos que los describen de manera más significativa.

Cuando crea los siguientes 500 objetos ORM, tendrá otro desafío. Incluso si les das nombres significativos, todavía hay demasiados para realmente esperar que todo sea obvio. Entonces, ahora tienes 2 problemas.

Si no hay forma de unir esos dos conjuntos de 500 tablas, entonces tienes 3 problemas. Piense en depurar el rendimiento de las consultas en el ORM y vaya al DBA con nombres que no reconoce. Piense en sus nombres cuidadosamente diseñados, que luego se deben ignorar cuando se crean informes que golpean directamente la base de datos.

Por lo tanto, me esforzaría mucho por utilizar los nombres de las bases de datos en el ORM.Pero me gustaría modificar algunas cosas:

• si un nombre es demasiado críptico para entenderlo - Yo trabajaría con el DBA para mejorar su nombre. Una forma fácil de transición a mejores nombres es a través de vistas. Lo ideal es que te deshagas del nombre confuso original con el tiempo.
• cambiar de guiones bajos a camelcase, etc. no debe considerarse un cambio en el nombre; es solo un cambio en el separador. Por lo tanto, use el nombre apropiado para su idioma.
• los prefijos de la base de datos se pueden descartar, en realidad solo son atributos del nombre de la tabla que han sido "desnormalizados" e injertados en el nombre. Pueden ser necesarios para evitar la duplicación si indican una subsección del modelo, pero en general pueden ser tan importantes.