Je veux comprendre le but des jeux de données lorsque nous pouvons communiquer directement avec la base de données à l'aide de déclarations SQL simples. Aussi, quel chemin va mieux? Mise à jour des données dans DataSet, puis les transférer à la base de données à la fois ou à mettre à jour la base de données directement?
4 Réponses :
J'aime généralement pratiquer cela, si je dois exécuter un groupe de procédés analytiques sur un ensemble de données volumineux, je remplirai un jeu de données (ou un jeu de données en fonction de la structure). De cette façon, il s'agit d'un modèle déconnecté de la base de données.
Mais pour les requêtes DML, je préfère les coups rapides directement à la base de données (de préférence par le biais de Procs stockés). J'ai trouvé que c'est le plus efficace et avec des requêtes bien réglées, elle n'est pas du tout mal sur la DB.
Les jeux de données supportent une architecture déconnectée. Vous pouvez ajouter des données locales, supprimez-la, puis en utilisant SQLADAPTER, vous pouvez tout commet à la base de données. Vous pouvez même charger le fichier XML directement dans DataSet. Cela dépend vraiment de vos besoins. Vous pouvez même définir des relations de mémoire entre les tables dans DataSet.
et BTW, à l'aide de requêtes directes SQL incorporées dans votre application est une très mauvaise façon de concevoir une application. Votre application sera sujette à "Injection SQL". Deuxièmement, si vous écrivez des questions comme celle intégrée dans l'application, SQL Server doit faire son plan d'exécution à chaque fois que les procédures stockées sont compilées et que l'exécution est déjà décidée lors de sa compilation. SQL Server peut également modifier son plan, car les données deviennent grandes. Vous obtiendrez une amélioration de la performance par cela. Au moins, utilisez des procédures stockées et validez la saisie indésirable en cela. Ils sont intrinsèquement résistants à l'injection SQL.
Les procédures stockées et le jeu de données sont la voie à suivre.
Voir ce diagramme:
edit: Si vous êtes dans .NET Framework 3.5, 4.0 Vous pouvez utiliser le nombre d'ormes comme l'embouteillage d'entité, NHibernate, subsonique. Les ormes représentent votre modèle d'entreprise plus de manière réaliste. Vous pouvez toujours utiliser des procédures stockées avec ORMS si certaines des fonctionnalités ne sont pas prises en charge dans les ormettes.
J'aimerais être en désaccord - je dirais que l'utilisation d'un mappeur d'objet-relation (comme l'entité structure, qui prend également judicieusement les procédures stockées) pour transformer vos données relationnelles en objets appropriés est la voie à suivre .....
@marc_s: Je serais également d'accord. Mais cette question concerne .NET Framework 2.0 et I lorsque j'ai dit "Procédures stockées et Dataset", je voulais dire qu'ils sont la voie à suivre pour Ado.net avec une bonne ancienne classe Sqlhelper.
Cette page explique dans Détail Dans quel cas vous devez utiliser un Dataset et dans quels cas vous utilisez un accès direct aux bases de données
Je veux comprendre le but des jeux de données lorsque nous pouvons communiquer directement avec la base de données à l'aide de déclarations SQL simples.
Pourquoi avez-vous de la nourriture dans votre réfrigérateur lorsque vous pouvez simplement aller directement à l'épicerie à chaque fois que vous voulez manger quelque chose? Parce que aller à l'épicerie à chaque fois que vous voulez une collation est extrêmement gênant .
Le but des jeux de données est de éviter de communiquer directement avec la base de données à l'aide de déclarations SQL simples . Le but d'un jeu de données est d'agir comme une copie locale bon marché des données que vous vous souciez de ne pas avoir à continuer à effectuer des appels de haute latence coûteux à la base de données. Ils vous permettent de conduire à la banque de données une fois , ramassez tout ce que vous allez avoir besoin pour la semaine prochaine, et tout cela dans le réfrigérateur dans la cuisine de sorte que c'est là quand vous en avez besoin. < / p>
aussi, de quelle manière est le meilleur? Mise à jour des données dans DataSet, puis les transférer dans la base de données à la fois ou à la mise à jour de la base de données directement?
Vous commandez une douzaine de produits différents à partir d'un site Web. De quelle manière vaut mieux: livrer les articles un à la fois dès qu'ils deviennent disponibles auprès de leurs fabricants ou attendre jusqu'à ce qu'ils soient tous disponibles et les expédier tous à la fois? La première façon, vous obtenez chaque article dès que possible; La deuxième manière a des coûts de livraison inférieurs. De quelle manière est mieux ? Comment diable devrions-nous savoir? C'est à vous de décider!
La stratégie de mise à jour des données qui est meilleure est celle qui fait la chose de manière à mieux satisfaire les désirs et les besoins de votre client. Vous ne nous avez pas dit ce que la métrique de votre client est "meilleure", la question ne peut donc pas être répondue. Qu'est-ce que votre client veut - les derniers trucs dès qu'il sera disponible, ou des frais de livraison bas?
Au fait, aucun client. Juste moi. C'est juste un système de gestion des actions que je fais pour la pratique. Étant donné que les données sont utilisées à plusieurs reprises pour la visualisation et la mise à jour, je suppose que les jeux de données sont la réponse. Mais toujours, il y a ce problème qu'en cas d'échec du système, tout le travail effectué par l'utilisateur sera perdu à moins que la base de données soit mise à jour pour chaque mise à jour effectuée par l'utilisateur. Est-il possible d'empêcher cela avec des jeux de données?
@Lizzie: C'est un excellent candidat pour une nouvelle question.