Discussion :

[Puiss51]

Bonjour,

je développe actuellement un soft en C# avec bdd SQL Server.
J'ai étudié et compris comment insérer ou mettre à jour mes données à l'aide de TableAdapter mais voila j'ai fait une grande fenetre avec pas mal de paramètres comment enregistrer au mieux les paramètres modifiés?
Faut il que je teste 1 par 1 les paramètres pour ne faire un update que si le paramètre diffère?
Faut il faire "bêtement" un UPDATE sur l'ensemble du tupple même si un seul paramètre a été modifié?
Faut il systématiquement faire un enregistrement du moindre paramètre changé dans la bdd?
une personne au boulot m'a parlé d'OVERWRITE mais je n'ai pas bien compris si c'est applicable pour mon problème.
Merci de votre aide.

[Puiss51]

j'essaie d'apporter mes éléments de réflexion au fur et à mesure :

pour les INSERT, je crée des objets en C# dont je laisse l'ID à 0 (qui correspond à la PK auto incrémenté dans ma BDD) donc au moment de quitter la fénêtre, je peux tester les lignes ayant un ID de 0 dans ma List C# pour faire un INSERT dans ma base.
Mais je me questionne toujours pour les UPDATE... j'ai bien eu l'idée d'un boolean qui passerait à true en cas de modification mais des gens plus pros que moi ne vont peut être pas approuver cette méthode...

[Michel.Priori]

Faut il que je teste 1 par 1 les paramètres pour ne faire un update que si le paramètre diffère?
Faut il faire "bêtement" un UPDATE sur l'ensemble du tupple même si un seul paramètre a été modifié?

Qu'on mette à jour une colonne ou plusieurs c'est le même travail de mise à jour pour la ligne de la table.
Un petit début de preuve de ce comportement est la logique d'un Trigger : les tables inserted et deleted ont le même nombre de colonnes que la table mise à jour (et non pas un nombre de colonnes différents selon les colonnes présentent dans l'ordre UPDATE)
Les mises à jour par les mêmes valeurs ne sont pas faites, les index ne sont pas mis à jour.

Donc la mise à jour de l'ensemble de la ligne n'est pas contre performant.
C'est plus long à écrire.
En cas de capture des requête (profiler) on ne saura pas dire pourquoi exactement l'update a été fait.
Si on chipote, du point de vue réseau, le volume "montant" des requêtes SQL sera plus lourd.

Faut il systématiquement faire un enregistrement du moindre paramètre changé dans la bdd?

Ben si tu veux pouvoir le relire, comment faire autrement ?

Remarque par rapport au titre : "INSERT et UPDATE multiples"
Par contre le fait de faire un INSERT "à vide" et de compléter la ligne par une série d'UPDATE peut avoir une incidence sur le stockage.
Si on peut éviter, c'est mieux.
Que se passe t'il ?

Les lignes sont stockées dans une page de 8192 octets dont 8060 pour les données.
Imaginons que l'insert "à vide" occupe 10 octets.
Imaginons que la table soit indexée cluster (c'est la norme sous SQL server)
On peut donc théoriquement insérer 806 lignes "à vide" par page.
Imaginons qu'on en insère plus de 1000 d'un coup ; on occupera plus d'1 page.

Maintenant si les lignes sont updatées en les faisant "grossir" par paliers de 10 octets jusqu'à atteindre 100 octets par ligne.
La contrainte de garder les lignes dans l'ordre (index cluster) + la limite par page => fragmentation d'index

La gestion de fragmentation des index rentre dans le cadre d'une tâche de maintenance.
Mais, si, on peut éviter de mettre le bordel, c'est mieux

[Puiss51]

je te remercie pour ta réponse bien étayée qui répond à la plupart de mes questions.

Juste une précision :

Faut il systématiquement faire un enregistrement du moindre paramètre changé dans la bdd?

Ben si tu veux pouvoir le relire, comment faire autrement ?

ce que je veux dire par là (car ce n'est pas forcément bien expliqué en effet) est soit :

- j'ajoute un boolean pour chaque paramètre modifié et j'UPDATE tout en une fois à la fin pour les boolean en true
- ou alors pour chaque paramètre modifié j'envoie aussitôt une requête update vers SQL server (ce que j'ai voulu dire dans le passage ci dessus)

mais je n'ai plus besoin de réponse, car grâce à ton explication, je pense maintenant m'orienter vers un UPDATE général des objets modifiés dans leur intégralité puisque ça ne demandera pas plus de ressource au server et ma requête n'en sera que plus simple.

Merci encore de ton aide.

[Michel.Priori]

je pense maintenant m'orienter vers un UPDATE général des objets modifiés dans leur intégralité puisque ça ne demandera pas plus de ressource au server et ma requête n'en sera que plus simple.

Attention :
Ce que j'ai dit :" ça ne coute pas plus cher de faire un update de plusieurs colonnes que pour une seule ligne"
Ce qui implique : "ça coute moins cher de faire un update de plusieurs colonnes que plusieurs update consécutifs pour une seule ligne"

Et je n'ai pas dit : "ça ne coute pas plus cher de faire un update de plusieurs lignes quand les mises à jour sont transparentes que d'éviter de mettre à jour certaines de ces lignes"
en l’occurrence ce serait même le contraire.

C'est "Update général des objets" qui m'a fait réagir.

[Puiss51]

Dans mon soft, j'ai créé des objets que j'instancie par tupple, on y retrouve tout les attributs de chaque tupple, y compris l'ID qui est la PK, je pense donc faire pour chaque objet un UPDATE table SET attribut1="nouvelle_valeur",attribut2="nouvelle_valeur",etc... WHERE ID="ID de l'objet" donc UPDATE toute la ligne plutot que certains attributs. Je ne vais pas updater toute la table

Comme il va y avoir plusieurs utilisateurs pour ce soft (en l'occurence 2, c'est un "petit" plusieurs ) je pensais faire des procédures stockées pour mes INSERT et mes UPDATE pour faire du transactionnel. J'ai une autre question sur ce sujet qui découle de cela mais je pense qu'il faut que je change d'emplacement sur le forum pour m'adresser aux spécialistes C#.

Merci pour tes précisions.

[Puiss51]

une dernière question (je m'excuse les questions me viennent les une après les autres) : je travaille principalement avec des vues qui me facilitent grandement la tache au niveau des jointures. Nous sommes bien d'accord que ce sont les tables que l'on met à jour, en aucun cas les vues?
Pour ma procédure stockée : peut on envoyer en paramètre d'entrée un tupple complet? (sous forme d'objet?) cela me parait trop simple,
Il faut décomposer par attribut? Si il faut décomposer par attribut, cela me parait plus simple de faire une procédure pour l'enregistrement d'un seul tupple et de faire un foreach dans mon programme C#, est ce le meilleur choix?

[Michel.Priori]

je pensais faire des procédures stockées pour mes INSERT et mes UPDATE pour faire du transactionnel.

Pour faire du transactionnel, les procédures stockées ne sont pas requises.

ça reste une très bonne idée de faire des procédures stockées.
Tout d'abord lors de l'évolution du schéma avoir une bibliothèque type API est bien pratique.
Ensuite la gestion des droits n'est que renforcée :
Imaginons que le compte de connexion de ton programme soit usurpé.
Si ce compte est Sysadmin (si si je l'ai vu) alors c'est la porte ouverte à toutes les fenêtres.
Si, maintenant, ce compte n'a le droit que de SELECT sur les vues et EXEC sur les procédures alors le pouvoir de nuisance est réduit aux seules actions opérationnelles. Ça reste énorme mais largement moins pire (possession du serveur au travers le compte de l'agent, backup, destruction des bases, cryptage, ...)

Au passage, ne pas hésitez à faire des schémas.
Ça simplifie la gestion des objets et des droits : 2 bonnes raisons.

[Michel.Priori]

Il y a différents intérêts de faire des procédures stockées.

D'une manière générale, avoir le code SQL sur le serveur SQL est aussi logique de stocker le "code PHP" sur le serveur WEB.
L'éparpillement de différents code en différents sites est plutôt une plaie lorsqu'on se lance dans une mise à jour, à cause de la gestion du périmètre.

Personnellement, je milite pour concevoir les accès aux bases de données comme le développement d'une API : une bibliothèque d'objets exposés dont leur mode de consommation est le plus "standard" possible. Le code interne est la compétence des développeurs de base de données.
Les procédures et les vues sont les moyens opérationnels d'arriver à faire ça.

Lorsqu'on fait son projet on pense que la base est un élément interne et dévolu au projet.
Ainsi associée, la base devient un mal nécessaire au développement.
Avec le temps, on constatera que ce n'est pas tenable, que les données sont des ressources d'entreprise et pas d'un projet.
Concevoir la base comme une ressource, ou plutôt comme une source, donne au projet la dimension qu'il mérite en l'asseyant sur des besoins multiples.

[Puiss51]

Merci pour ce point de vue très intéressant, je vais creuser cette notion de API