Discussion :

[colombero]

Bonjour,
Je suis un peu perdu avec les DataSet et leurs mmode de fonctionement.
en effet j'ai du mal à voir les focntionnement de ce dernier.
Peut-il êtr créé sans qu'il y est un ebase de données initiae ?
Comment les synchronisations se font-elles avec la base de donnée dans les différents cas de update insert select delete.
Les contraintes également m'intéressent si vou pouvez me donner des explis la dessussuper
Merci à vous
Fred

[bidou]

Peut-il êtr créé sans qu'il y est un ebase de données initiale ?

oui

Comment les synchronisations se font-elles avec la base de donnée dans les différents cas de update insert select delete.

par le biais de commande que tu peux soit avoir dans un DataAdapter, soit gérer directement, soit générer par un command Builder

Les contraintes également m'intéressent si vou pouvez me donner des explis la dessussuper

ca fonctionne comme les contraintes de sgbd, unicité, clef, intégrité

[colombero]

Bonsoir,
Merci pour tes informations.
Mais dans le cas de la création d'un DataSet sans base de donnée, cela n'a aucun intérêt non ?
Je veux dire que si tu crée un DataSet et des DataTable il faudra leur donner un élément referençant une table du SGBD non ?
Quel est l'intérêt d'un DataSet dans un cas pratique ?
Merci de tes infos.
A+ Fred

[bidou]

Retournons le problème.

Un dataset, c'est une construction d'objets simulant une gestion de type SGBD des données, loacalement à ton application.

La question pour l'utiliser n'est pas ai-je une base de données comme source de mes données mais ai-je un intérêt à avoir un pseudo SGBD local. On peut faire des applications utilisant des base de données sans avoir l'utilité d'un dataset, et avoir des applications sans base de données avec un dataset. Tout est question de volume et d'organisation des données, du type d'utilisation que ton application induit et des méthodes de gestion que tu souhaites avoir.

[B.AF]

Bonjour,

Utilisant souvent .NEt dans des cas de d'applications utilisant enormement de donnees,

Je voudrai eclairer ta lanterne sur ce sujet :

Deja, le dataset tel qu'exploiter au travers de VS 2003 ou 2005 n'est qu'une representation de l'IDE.
Deja, il faut se detacher un peu du contexte visual studio, qui effectivement dans ses divers assistants 'incite' plus ou moins a recourir aux datasets pour limiter la programmation.

Voici des reponses pratiques

1 - Le dataset
Le dataset doit etre quelque part utilise avec parcimonie si tu souhaites monter en charge, du fait premierement de la necessiter de rebuilder le projet a chaque modification si tu as utilise les assistants de vs, et surtout parce que si tu restes en client serveur, le dataset peut vite etre gourmand en memoire.
En revanche, il y a souvent un abus ou une confusion issue du premier framework.
Le conteneur de donnee du dataset et bien la collection de datatables presentes dans le dataset.
Comment le conceptualiser ?
D'un point de vue pragmatique, un dataset est un schema de donnees, au meme titre qu'un schema de BD relationnel standard.
Cependant libre a toi de t'en servir autrement que par la 'parallelisation' de tes tables et de leurs contraintes.

Dans un dataset, tu vas donc trouver tres basiquement:
Des datatables, contenant
- des colonnes
- des indexes
- des types
- eventuellement des relations avec des regles de maj
Tout cela etant relativement similaire au proprietes d'un table d'un SGBD.

Des tableadapters contenant
- Les parametres SQL (select, insert, update,connexion)
- Les differentes methodes (getByID,etc,etc...) que tu peux generer (Methode de remplissage ou de mise a jour que tu implementes depuis les donnees du dataset)

Dans chaque table, tu trouves des datarows.(lignes de donnees) et des column

En outre, tu peux imposer programmatiquement des regles de gestion aux evenements (mise a jour d'un cellule d'une row), un defaultage par regle...

Globalement, tu peux avec un dataset, delocaliser dans des objets les traitements de base de donnees et minimiser ton acces aux donnees a des select, insert,update et delete, sans avoir de traitement SQL 'complexe'.
Dans ce cas, il y une abstraction tres relative du moteur de BD que tu adresses. (si tu utilises bien entendu du SQL norme tant au niveau du langage que des types utilises dans ta vraie DB)

En revanche, il faut rester conscient d'une chose : le dataset est aussi un objet qui dispose d'une taille consequente du volume de donnees qu'il recoit.

Prenons un exemple :

Imaginons que j'ai une table de ma db contenant :
Table "Client"
IdUser --> Pk, int
UserName ---> Char(30)

En utilisant Vs, je vais automatiquement creer dans le dataset, la datatable suivante :
Client
IdUser ---> UInt32
UserName ---> String, MaxLenght =30

Vs va creer automatiquement :
L'insert, l'update, le select, au niveau SQL
Ainsi que la methodes get et fill (remplissage du dataset)

En revnache lorsque tu vas instancier ton dataset, tu seras oblige des lors par le fill de prendre TOUS les enregistrements de la table.

Ce que nous ne cherchons pas necessairement. La encore, en implementant d'autres methodes du table adapter (SearByNameLike, etc,etc...a toi de definir), tu peux palier a cette question, mais si par exemple tu devais vouloir lier ta datatable Client a disons une table client_ordres, avec une relation pour creer une notion de maitre detail dans une forme, tu pourrais vite t'amuser via les methodes des tablesadapters et les relations, les temps de reponse, les volumes a gerer des situations un peu 'chiantes'.

Pourquoi ? Parce que Ok, developper sur son PC, son OS sans contraintes de securite avec la DB en local avec le developpeur en seul utilisateur, 'cest tres tres loin de ce que tu peux esperer voir sur un vrai site, avec des vraies donnees, de vraies profondeurs d'historiques et surtout un modele qui risque de contenir un peu plus de deux tables.

Bref, mon seul et unique conseil : Ne t'en sers que si tu en as vraiment besoin et surtout pas sur du gros volume. Encore moins en .Net Remoting, la tout seul, tu trouveras jolie les enveloppes soap et relativement facile a creer, mais le jour ou tu auras 100 utilisateurs dessus sur le meme reseau, avec le meme serveur d'application, a moins d'avoir une factory pour GZipper en mememoire les datasets, tu risques de mettre tout le reseau a genoux.
(bah oui, entre les donnees, la description du schema, les enveloppes etc,etc, ca devient tres vite GROS).



2 - Acceder directement aux donnees

Ici, je ne saurai que te preconiser de jeter un oeil au library enterprise de microsoft. Elles permettent effectivement de mieux dissocier l'acces aux donnees de la representation sans necessairement exploiter le dataset.
donnees de l'environnement : il faut tout coder et le dataset n'est pas une etape obligatoire.

En fait il y a une encapsulation des methodes d'acces aux donnees (bref, une gestion de la complexite ambiante).
Cela te permet :
De generer des Datareaders (eq. au recordset)
Des generer des datasets
Des transactions systeme
Des Db multiples

Ce que je trouve interessant, c'est que c'est justement peu ou pas assiste par l'Ide :
Tu peux donc toi tout seul binder du SQL a des objets qui realiseront un vrai traitement fonctionnel, des transactions plus 'transparentes'.

Et surtout il y a une classe specialisee dans le caching : utilie pour des donnees statiques et couramment employees, a condition cependant qu'elles ne necessitent pas un update
frequent sinon tu devras gere une complexite supplementaire.

3 - N'utiliser que les datasets

Alors la...Oui tu peux utiliser un dataset tout seul.

Soit :
L'utiliser pour stocker temporairement des donnees a traiter.
La encore, a moins qu'il soit tres types et que tu choisissent de t'appuyer sur des colonnes calculees pour te faciliter la vie,
Il me semble plus agreable a comprendre et plus facile a gerer d'utiliser des collections d'objet, tableaux, hashing...
A toi de voir et d'essayer en fonction de ce que tu veux faire.
L'utiliser pour stocker des donnees (read / write en XML) sur une Db locale
Alors la, je suppose que c'est davantage concu pour des besoins de serialisation que de stockage reel.
En effet, et du au concepteur de Visual Studio, si tu veux transferer un dataset d'une form a une autre tu es soit ...
Obliger de coder tout le binding a la main (dataset, binding des composants,etc,etc....)
Obliger de bidouiller la methode init generee automatiquement pour annuler la nouvelle instance du dataset (et la, c'est magique, du meme coup tu ne pourras plus te servir du concepteur de forms....lol)
Dans la pratique, je m'en sers uniquement si la connexion Db est tombee (serveur 'mort', exception quelconque, pour sauvegarder le traitement et pouvoir reprendre le traitement ulterieurement)

4 - Alors finalement

Oui dans Vs, c'est sexy, mais comme tout assistant, ca ne fait pas tout.
C'est une methode elegante de traiter les donnees, en revanche, elle presente pour moi un inconvenient majeur dans son usage :
Il faut gerer la lourdeur et parfois la complexite (Va mettre un jour une hierarchie a quatre niveau avec la gestion des erreurs : COURAGE !)
Dans une logique client / serveur, il faut parfois sur des gros volumes implementer des proprietes etendues pour faker un simili "Lazy loading" (Ne charger dans la table en relation que les donnees necessaires)

Exemple :
Je charge dans une tables 50 actions avec des devises USD, YEN, et EUR.
A priori, j'ai besoin pour chaque devise de connaitre :
Le taux de change jour (9 au total, donc certains peut etre calcules)
La decimalisation de la devise

Ma table devise contient 150 references de devises et 4000 taux de changes
Je fais quoi :
La vraie mauvaise methode, c'est tout charger en dataset et utiliser les relations et autre binding source pour gerer 'facilement'
parce que demain, 100 utilisateurs...Ca fera super mal.
Moi, pour faire ca, je passe par un objet devise et un objet action, la library enterprise. La propriete devise des actions retourne une instance d'une devise.
Il me suffit donc de creer un indexeur et trois objets.
Derriere, je peux au travers d'une collection acceder aux devises et calculer mes taux.

C'est net, c'est du code clair, pas de code genere et surtout, je maitrise bien mes volumes de donnees.

Voila pour mon experience, d'aucun sera d'accord ou pas, mais comme tout projet , juste commencer par se demander, pour quoi, pour qui, et quel volume.








2 - Acceder directement aux donnees

Ici, je ne saurai que te preconiser de jeter un oeil au library enterprise de microsoft. Elles permettent effectivement de mieux dissocier l'acces aux donnees de la representation sans necessairement exploiter le dataset.