Linq a SQL y modelo de base de datos grande

En primer lugar, soy Linq a Sql novato, así que sea amable :).Linq a SQL y modelo de base de datos grande

Tengo una aplicación ASP.Net existente desarrollada en los últimos 3.5 años. Tiene un modelo de datos bastante grande debajo, alrededor de 350 tablas. Estoy tratando de hacer algunas cosas nuevas con Linq a SQL.

La primera impresión es que el diseñador de linq y SqlMetal están diseñados para bases de datos no mayores que el ejemplo de NorthWind. Aquí están algunos problemas que tengo:

tengo tabla Products que se necesita en un montón de lugares (inventario, facturación, producción, ...). Si pongo la tabla Products en cada archivo dbml, el diseñador de linq creará la clase Product en cada uno de ellos. No quiero eso. Quiero una sola clase Product.
Tengo DataContext sobre el envío. Necesita alrededor de 40 tablas. Esto hace que el archivo dbml sea muy difícil de administrar. ¿Hay alguna manera de crear archivos dbml más pequeños y luego incluirlos (como referencia) en algún dbml "principal"?

Por el momento, me gusta mucho Linq, pero creo que todavía falta una herramienta de diseño para algo más grande que 10 tablas.

Mi solución ahora es crear modelos más pequeños con el diseñador Linq y luego fusionarlos manualmente (agregando propiedades y referencias), por lo que se generarán muchos códigos, pero también habrá mucho trabajo manual.

¿Echaba de menos algo grande o es este estado de cosas actual con Linq to Sql?

Fuente

2008-11-08 zendar

No tengo una respuesta, pero estoy interesado en saber esto también, ya que he notado lo mismo. Los métodos que está usando son lo que pensé que haría si tuviera muchas tablas. – dtc

No entiendo por qué SqlMetal no es la respuesta a su pregunta? Funcionó bien para mí con grandes bases de datos de múltiples tablas. Acabo de conectar un script por lotes al menú "Herramientas externas" en Visual Studio para poder reconstruir el ORM con un solo clic. –

@James McCormack: podría agregar una respuesta y describir cómo se organizan las clases. Lo que me gustaría es tener el inventario de ensamblaje y dentro de unas 20-30 clases que correspondan a la misma cantidad de tablas. Luego ensamble Ventas, luego Finanzas.No encontré una manera fácil de automatizar esto, así que recurrí a esto: crear dbml para un número pequeño de tablas y luego editar código manualmente. ¿Sabes si se ha mejorado SqlMetal for .Net4? – zendar

-5

Si yo fuera tú, estaría utilizando Entity Framework ya que esto se recomienda la MS ORM en el futuro Microsoft kills Linq to SQL

Fuente

2008-11-08 20:48:52 user17060

No creo que esto responda la pregunta y creo que EF tiene los mismos inconvenientes cuando hablamos de tratar de modelar 350 tablas en un solo archivo EF o grupos de archivos más pequeños. – dtc

El diseñador EF es aún peor en el manejo de modelos grandes. Ambos diseñadores necesitan un enfoque "paginado" que permita fragmentar los modelos en vistas pequeñas y digeribles. O función de división/combinación que permite que muchos modelos pequeños de diseñadores se fusionen en un único modelo de objetos. – KristoferA

¿Se ha encontrado este artículo en MSDN?

http://msdn.microsoft.com/en-us/library/bb387007.aspx

Parece que hay una herramienta de línea de comandos para generar el modelo de objetos sin necesidad de utilizar el diseñador visual en VS.net.

Fuente

2008-11-08 23:37:55 dtc

Eso sería SqlMetal que mencionó el OP. – hangy

Ok, no estaba seguro porque el artículo dice sobre el generador de código SQL Metal: "Modelar bases de datos grandes se hace mejor usando esta herramienta". – dtc

¿Por qué quiere múltiples archivos dbml? Solo pegúelos a todos en uno. Así es como debe funcionar.

Fuente

2008-11-09 00:14:13 GeekyMonkey

Creo que uno de los problemas es que cuando comienzas a agregar una gran cantidad de bases de datos, el diseñador comienza a ser imposible de usar. – dtc

¿Trataste de poner 350 tablas en un dbml? – zendar

Todo en uno es bueno para los modelos pequeños. Sin embargo, el punto de tener un diagrama modelo es obtener una visión general. Dividir el modelo en áreas temáticas facilita la visión general; un modelo de 300 mesas es imposible de ver. – KristoferA

bueno, mi solución fue utilizar la opción SQLMetal /code para crear clases simples en un archivo .cs en lugar de un archivo DBML, y usar clases parciales en un archivo separado para extender las clases ORM generadas.

Sé que esto no resuelve el problema de dividir partes de su base de datos en diferentes ensamblados ORM. Simplemente descubrí que sin el dolor de cabeza del DBML/Designer, manejar una gran cantidad de clases en un archivo .cs no era demasiado mal

Fuente

2010-09-09 10:22:40

Linq a SQL y modelo de base de datos grande

Respuesta

Cuestiones relacionadas