Conception de jeu de données .NET

Question

Je suis préoccupé par la conception de jeux de données.

On m'a dit qu'il serait bon d'avoir un jeu de données pour chaque table à des fins de maintenance. Étant donné que des changements fréquents dans les tables de base de données sont attendus, le fait d'avoir un jeu de données incluant chaque table serait pénible à effectuer la modification correspondante dans l'application. Q. Est-ce une bonne approche d'avoir un ensemble de données pour chaque table (je finirais par avoir 30 ~ 40 jeux de données pour chaque table DB en utilisant la procédure stockée)?

J'ai un projet distinct pour les ensembles de données communément utilisés. chaque projet inclut "dataset project" comme référence, et l'utilise en incluant l'ensemble de données nécessaire dans Forms, classes, etc.

Q. Cette approche rend-elle le système entier plus lent? Si j'ai un ensemble d'ensembles de données en tant que projet séparé, ce serait bénéfique, car il sera plus facile de faire une modification (j'ai seulement besoin de faire une modification à un endroit)

Answer 1

Performance sage ayant plusieurs jeux de données (et plusieurs requêtes)) est généralement plus lent. Cependant, du point de vue de la maintenance, disposer d'une seule requête et d'un ensemble de données par table est nettement plus facile à gérer.

Tout dépend de la relation entre les tables. Si vous pouvez utiliser une requête hiérarchique pour obtenir toutes les données liées et les mettre dans un ensemble de données, je le recommanderais. Si les tables ne sont pas liées du tout, la séparation des ensembles de données et des requêtes pourrait être le meilleur itinéraire.

Answer 2

Je trouve que la meilleure approche consiste à avoir un jeu de données par scénario. Le gros inconvénient est que la définition de votre table est répartie sur plusieurs ensembles de données (si une table est référencée dans plus d'un scénario) ce qui est évidemment mauvais pour la maintenance si le schéma change; cependant les avantages sont si alambiqués que les changements que vous devez apporter à vos données sur le client, l'ensemble de données peut faire tout le travail pour vous suivre le changement dans les relations/suppression des enfants/insertion des enfants, mais de nombreux niveaux de hiérarchie , et cela rend la maintenance de votre application que l'interface utilisateur change.

Ce sont les deux principaux facteurs pour moi - trouver un compromis entre la maintenance en ce qui concerne les modifications apportées au schéma, et la maintenance en ce qui concerne les modifications apportées à l'interface utilisateur. Le jeu de données one-table-per-dataset-all-tables-in-one réduira votre travail dans la maintenance DB, mais cela signifie que vous devrez recoder une grande quantité chaque fois que les exigences d'un écran particulier changeront. Trouver le bon équilibre pour votre application est le meilleur plan.