Estoy trabajando con SQL Server, y la mayoría de las tablas tienen columnas de identidad de tipo int. Y ahora, acabo de encontrar un libro, que dice que no es una buena idea usar este mecanismo. ¿Cuáles son los contras/pros de usar columnas de identidad cuando se usa NHibernate como ORM?Columnas de identidad del servidor SQL con NHibernate: para usar o no usar
No soy un experto en NHibernate, pero, por lo que yo entiendo, el uso de columnas de identidad rompe el UnitOfWork y ocasiona viajes de ida y vuelta adicionales a la base de datos.
Fabio Maulo (entonces líder del proyecto de NHibernate, no estoy seguro de si todavía es hoy en día) tiene un blog donde explica esto en detalle:
Identity: The never ending story
Aquí hay otro (más) blog con código de ejemplo:
NH2.1.0: generators behavior explained
Sin embargo, cabe destacar que ambas entradas del blog son unos tres años y hablan de NH 2.1.0, y la versión actual a partir de hoy es NH 3.3. Pero supongo que el problema descrito por Fabio todavía existe hoy.
Creo que hay un problema mayor ... Sí, el concepto de "unidad de trabajo" y todo es importante. ¡Pero la felicidad de SQL Server también es importante! Los GUID crean malas claves primarias en SQL Server (http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx) Así que en NH 3.x, ¿es factible usar identidad? (¡Necesitamos saber!) – Jonesome
No hay motivo por el que NHibernate no pueda generar SQL que devuelva la columna de identidad recién insertada en el mismo viaje que crea el registro. –
No, el punto es: cuando creas 20 objetos nuevos en un UnitOfWork, NH tiene que hacer un viaje redondo a la base de datos para cada uno con el fin de obtener el ID a través de Identity ... lo cual derrota el propósito de un UnitOfWork . Con otras estrategias de generación de ID, NH solo necesita hacer ** un ** viaje de ida y vuelta al final. –
No importa si se trata de una columna de identidad o no. La función de un ORM es asignar las entidades de datos a la base de datos para no dictar la estructura/diseño de la base de datos. He utilizado una implementación con columnas de identidad y funciona bien.
Sí, funciona. Es una cuestión de eficiencia. El uso de una columna de identidad u otro generador de claves primarias controlado por base de datos evita que NHibernate realice una agrupación de instrucciones INSERT. –
@Oskar - debe escribir una respuesta :) Gracias – dragonfly
La mayoría de las bases de datos admiten inserciones por lotes de una manera que devuelve la columna de identidad. Consulte la cláusula 'Output' en SQL Server para ver un ejemplo. (Si NHibernate lo hace o no es otro asunto). –
Bueno, desde una perspectiva de base de datos, el profesional es que hay una manera robusta de identificar de manera única una fila en una tabla, especialmente dado que la tabla puede tener miles o millones de filas, etc. ¿De qué otra manera diferenciaría las filas? ¿Hay alguna otra ID/columna de referencia que sea única? ¿Se aplica la singularidad usando una restricción ÚNICA? –
@ChrisCannon La pregunta y la recomendación en las que se basa es ** no ** sobre la eliminación de la clave principal, pero solo sobre cómo se generan los valores de la clave principal. NHibernate puede funcionar más eficientemente cuando administra la generación de la clave primaria. –
He buscado en Google y no veo una buena respuesta a esta pregunta. Creo que la pregunta está abierta. NH quiere usar GUID ... pero los GUID son horribles como claves principales en SQL Server (ver http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering- key.aspx). En nuestra base de datos, que es grande, podríamos ahorrar DOZENS de GB simplemente cambiando de GUID a identidad. Es hora de escribir mejor sobre este tema ... – Jonesome