INSERT et UPDATE multiples

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.

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...

Citation:

---

Envoyé par Puiss51

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.

Citation:

---

Envoyé par Puiss51

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 ;)

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

Juste une précision :

Citation:

---

Citation:

---

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.

Citation:

---

Envoyé par Puiss51

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.

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.

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?

Bonjour,

Si, vous pouvez passer par les vues pour mettre à jour.
Dans le cas d'une vue simple (pas de jointure, pas d'agrégat,...), vous pouvez directement faire vos commande insert/delete/update sur la vue.

Si la vue est plus compliquée, il faudra alors passer par un trigger INSTEAD OF afin de définir les règles de gestion pour la mise à jour des tables sous jacentes.

Pour ce qui est de vos procédures, vous pouvez passer chaque valeur dans une variable scalaire, ou bien en effet passer la ligne complète (voire plusieurs) en passant par un paramètre de type TABLE, ou bien un paramètre scalaire de type XML a parser ensuite...

Citation:

---

Envoyé par Puiss51

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.

Citation:

---

Envoyé par Puiss51

une procédure pour l'enregistrement d'un seul tupple et de faire un foreach dans mon programme C#, est ce le meilleur choix?

---

Je rejoint aieeeuuuuu quand il parle de paramètre TABLE ou XML.
Les ordres INSERT ... SELECT ... et UPDATE ... FROM ... vont vous plaire ;)

https://docs.microsoft.com/fr-fr/sql...ql-server-2017

Je n'ai pour l'instant qu'un seul tupple avec peu de paramètres à passer, je vais donc me contenter de variables scalaires mais je prends bien note de ce que vous m'avez dit là pour la suite de mon programme.
Voici ce que j'ai écrit comme procédure, elle fonctionne impeccable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE INSERT_ADDITIF @nom Varchar(50), @CAS varchar(12), @ENUMBER varchar(20) AS BEGIN BEGIN TRANSACTION AdditifInsert SET NOCOUNT ON; SET IDENTITY_INSERT dbo.T_ADDITIF OFF IF @nom IS NOT NULL INSERT INTO dbo.T_ADDITIF ([ADD_NOM],[ADD_ENUMBER],[ADD_CAS]) VALUES (@nom,@CAS,@ENUMBER) END COMMIT TRANSACTION AdditifInsert GO

---

Merci pour votre aide à tous les deux.

La gestion de transaction n'est pas nécessaire ici, tu fais juste une insertion.

Je fais un ajout automatique de l ID qui sert de PK, il n'y a pas de risque qu'il y ait un doublon si 2 utilisateurs font une insertion simultanément ?
Tu ne geres les transactions que pour les UPDATE ?
Merci pour ta remarque en tout cas

Citation:

---

Envoyé par Puiss51

Je fais un ajout automatique de l ID qui sert de PK, il n'y a pas de risque qu'il y ait un doublon si 2 utilisateurs font une insertion simultanément ?
Tu ne geres les transactions que pour les UPDATE ?
Merci pour ta remarque en tout cas

---

Dans un SGBD Relationnel TOUT est transactionné sans exception.
1) les commandes de définition des objets : CREATE..., ALTER…, DROP...
2) les commandes de manipulation des objets : INSERT, UPDATE, DELETE, MERGE, TRUNCATE, SELECT…
3) les commandes de définition des privilèges : GRANT…, REVOKE...


La nécessité de gérer des transactions explicites n'apparait que dans le cas ou diverses commandes doivent être utilisée conjointement en tout ou rien.

A +

ha ok. Merci pour cette précision

Citation:

---

Envoyé par SQLpro

La nécessité de gérer des transactions explicites n'apparait que dans le cas ou diverses commandes doivent être utilisée conjointement en tout ou rien.

---

Tout = Commit
Rien = Rollback

Le fait de créer une transaction explicite (BEGIN TRANSACTION) nécessite une conclusion.
Sous SQL server, on est en "mode transaction par défaut".
Ainsi un INSERT, UPDATE ou DELETE sera implicitement commité si la commande n'est pas encapsulée par une transaction supérieure.

Généralement lorsqu'on crée une transaction explicite on gère, dans le même code, les deux conclusions possibles.

Il faut donc un
ERROR
trans rollback
A la fin?

Citation:

---

Envoyé par Michel.Priori

TSous SQL server, on est en "mode transaction par défaut".

---

Plus exactement AUTOCOMMIT.

Chaque ordre SQL est encapsulé dans un jeu de commande délimitant les frontières des transactions.
Le scénario est le suivant :
BEGIN TRANSACTION --> invisble
Ma commande SQL
Si exception alors ROLLBACK sinon COMMIT --> invisible

A +

Si je n'envoie qu'une instruction qui sera donc en transactionnel implicite, ai je un intérêt a faire une procédure stockée ?

J'ai trouvé un site qui explique que même pour des traitements simples, une procédure stockée est intéressant car elle réduit les informations envoyées vers le serveur et donc le débit réseau

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.

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