Quelle est la meilleure façon de gérer la mise à jour de plusieurs colonnes

Question

Si j'ai un formulaire de profil avec 20 champs, un utilisateur peut mettre à jour sur une page. Il semble que ce serait une perte d'exécuter une instruction de mise à jour qui mettrait à jour chaque colonne si l'utilisateur n'a modifié que deux champs.

Je me demandais quelle serait la meilleure façon de gérer cela pour la meilleure performance.

Depuis que j'ai seulement 20 champs ce n'est pas vraiment un problème mais je me demande juste pour le développement futur de l'endroit où peut-être il pourrait être plus.

Qu'est-ce que tout le monde fait, mettez-vous simplement à jour chaque colonne pour cette ligne?

Answer 1

Des outils comme Entity Framework (ou d'autres outils ORM) géreront cela pour vous, pour "libre".

Ils suivent ce qui a changé dans vos objets et émettent une instruction personnalisée UPDATE qui ne mettra à jour que les colonnes qui ont réellement changé.

Plus besoin de vous soucier de ces détails. Tous pris en charge pour vous. Essayez-le!

Ressources:

• Entity Framework in the MSDN Data Developer Center - tonnes de documents, des livres blancs, des exemples de code, des vidéos et plus

• Absolute Beginner's Guide to Entity Framework

• MSDN Library - Entity Framework Overview (.NET 4)

• ASP.NET site - Entity Framework avec beaucoup de tutoriels sur comment utiliser EF avec ASP.N ET (Webforms et MVC) applications

Answer 2

Votre paquet réseau moyen est long de 1500 octets. Cela peut probablement contenir vos 20 champs avec facilité. Vous ne sauvegarderez donc pas de charge réseau en mettant à jour moins de 20 champs. SQL Server stocke les données dans des pages de 8000 octets. Si vous mettez à jour 1 bit, SQL Server l'écrira comme une page entièrement modifiée: 8000 octets de données. Vous ne sauvegardez donc pas d'activité disque en mettant à jour moins de 20 champs.

L'optimisation des performances est souvent une erreur. Les bases de données sont très rapides ces jours-ci. Optimiser pour un code simple et clair à la place.

Answer 3

Je ne peux qu'imaginer récupérer l'enregistrement courant de DB, comparer le champ par le champ avec l'entrée d'utilisateur et alors mettre à jour seulement les champs changés.

Ce sera plus cher que de simplement mettre à jour tous les champs dans une seule instruction de mise à jour, donc j'irais avec un choix de mise à jour unique.

Answer 4

CREATE PROC [dbo].[UpdateMe] 
(
    @pkey int, 
    @Col1 int = null, 
    @Col2 int = null, 
    ..., 
    @Col20 int = null 
) 
AS BEGIN 

    UPDATE [Table] 
      SET Col1 = ISNULL(@Col1,Col1), 
      Col2 = ISNULL(@Col2,Col2), 
      ... 
      Col20 = ISNULL(@Col20,Col20) 
    WHERE pkey = @pkey 

END 

Gardez une trace de ce qui a changé sur le client et envoyer des choses en conséquence. Si vous vous inquiétez d'envoyer beaucoup sur le réseau, utilisez des paramètres nommés et n'envoyez que ce qui a changé. Comme il y a des défauts sur la procédure, cela ne vous coûte rien. Le temps de recherche en sql est là où le coût est, donc la mise à jour d'une colonne à elle-même devrait être assez bon marché.