Quiero entender el propósito de los conjuntos de datos cuando podemos comunicarnos directamente con la base de datos usando declaraciones SQL simples. Además, ¿qué camino es mejor? ¿Actualizando los datos en el conjunto de datos y luego transfiriéndolos a la base de datos de una vez o actualizando la base de datos directamente?¿Cuál es el propósito de los conjuntos de datos?
Quiero entender el propósito de conjuntos de datos cuando se puede comunicar directamente con la base de datos utilizando declaraciones SQL simples.
¿Por qué tiene comida en su refrigerador, cuando puede ir directamente a la tienda de comestibles cada vez que quiere comer algo? Debido a que ir a la tienda de comestibles cada vez que quiere un bocadillo es extremadamente inconveniente.
El propósito de los DataSets es evitar la comunicación directa con la base de datos utilizando declaraciones SQL simples.El objetivo de un DataSet es actuar como una copia local barata de los datos que le interesan para que no tenga que seguir realizando costosas llamadas de alta latencia a la base de datos. Le permiten conducir al almacén de datos una vez, recoger todo lo que va a necesitar para la próxima semana, y ponerlo en la nevera en la cocina para que esté allí cuando lo necesite.
Además, ¿qué camino es mejor? ¿Actualizando los datos en el conjunto de datos y luego transfiriéndolos a la base de datos de una vez o actualizando la base de datos directamente?
Solicita una docena de productos diferentes de un sitio web. ¿Qué camino es mejor: entregar los artículos uno a la vez tan pronto como estén disponibles por parte de los fabricantes, o esperar hasta que estén disponibles y enviarlos todos a la vez? De la primera forma, obtienes cada artículo lo antes posible; la segunda forma tiene menores costos de entrega. ¿De qué manera es mejor? ¿Cómo diablos deberíamos saber? ¡Depende de ti decidir!
La estrategia de actualización de datos que es mejor es el que hace la cosa de una manera que responda mejor a sus clientes de los deseos y necesidades. No nos ha dicho cuál es la métrica de su cliente para "mejor", por lo que la pregunta no puede ser respondida. ¿Qué quiere tu cliente, las últimas novedades tan pronto como esté disponible, o una tarifa de envío baja?
Normalmente me gusta practicar que, si necesito realizar un montón de procesos analíticos en un gran conjunto de datos, llenaré un conjunto de datos (o una tabla de datos dependiendo de la estructura). De esta manera es un modelo desconectado de la base de datos.
Pero para consultas DML prefiero las visitas rápidas directamente a la base de datos (preferiblemente a través de procs almacenados). He encontrado que esta es la más eficiente, y con consultas bien ajustadas no está nada mal en el db.
Los conjuntos de datos admiten arquitectura desconectada. Puede agregar datos locales, eliminarlos y luego usar SqlAdapter puede enviar todo a la base de datos. Incluso puede cargar el archivo xml directamente en el conjunto de datos. Realmente depende de cuáles son tus requisitos. Incluso puede establecer relaciones de memoria entre tablas en DataSet.
Y, por cierto, el uso de consultas SQL directas incrustadas en su aplicación es una forma realmente muy mala y pobre de diseñar aplicaciones. Su aplicación será propensa a "Inyección Sql". En segundo lugar, si escribe consultas como la incrustada en la aplicación, Sql Server debe ejecutar su plan de ejecución cada vez que se compilan los procedimientos almacenados y su ejecución ya está decidida cuando se compila. Además, el servidor Sql puede cambiar su plan a medida que los datos crecen. Obtendrás una mejora del rendimiento con esto. Por lo menos, use los procedimientos almacenados y valide la entrada de basura en eso. Son inherentemente resistentes a la inyección Sql.
Los procedimientos almacenados y el conjunto de datos son el camino a seguir.
ver este diagrama:
Editar: Si usted está en NET Framework 3.5, 4.0 puede utilizar varios ORM como Entity Framework, NHibernate, subsónico. Los ORM representan su modelo de negocio de forma más realista. Siempre puede usar procedimientos almacenados con ORM si algunas de las características no son compatibles con ORM.
Por ejemplo: Si está escribiendo un CTE recursivo (Expresión de tabla común) Los procedimientos almacenados son muy útiles. Te encontrarás con demasiados problemas si utilizas Entity Framework para eso.
Me gustaría no estar de acuerdo. Diría que el uso de un mapeador relacional de objetos (como Entity Framework, que también admite procedimientos almacenados) para convertir los datos relacionales en objetos adecuados es el camino a seguir ..... –
@ marc_s: También estoy de acuerdo. Pero esta pregunta está relacionada con .Net framework 2.0 y yo cuando dije "Procedimientos almacenados y conjunto de datos" quise decir que son el camino a seguir para Ado.Net junto con la buena clase de SqlHelper. – TCM
@GertArnold: Gracias por detectar. Lo he corregido – TCM
This page explica en detalle en qué casos se debe utilizar un Dataset y en qué casos se utiliza el acceso directo a las bases de datos
gracias por la explicación: D – Lihini
Por cierto, no hay cliente. Solo yo. Es solo un sistema de gestión de stock que estoy haciendo para la práctica. Dado que los datos se usan repetidamente para ver y actualizar, creo que los conjuntos de datos son la respuesta. Pero aún así, existe el problema de que, en caso de falla del sistema, todo el trabajo realizado por el usuario se perderá a menos que la base de datos se actualice para cada actualización realizada por el usuario. ¿Es posible evitar esto con conjuntos de datos? – Lihini
@Lizzie: Es un gran candidato para una nueva pregunta. –