2010-05-24 7 views
0

J'ai un site piloté par les données avec de nombreuses procédures stockées. Ce que je veux, à terme, être en mesure de faire est de dire quelque chose comme:Procédures stockées SQL Server - colonne de mise à jour basée sur le nom de la variable ..?

For Each @variable in sproc inputs 
    UPDATE @TableName SET @variable.toString = @variable 
Next 

Je voudrais qu'il soit en mesure d'accepter un certain nombre d'arguments.

Il va fondamentalement faire défiler toutes les entrées et mettre à jour la colonne avec le nom de la variable avec la valeur de la variable - par exemple la colonne "Nom" serait mise à jour avec la valeur de @Nom. Je voudrais essentiellement avoir une procédure stockée pour la mise à jour et une pour la création. Cependant, pour ce faire, je devrai être capable de convertir le nom réel d'une variable, pas la valeur, en une chaîne.

Question 1: Est-ce possible en T-SQL, et si oui, comment?

Question 2: Y a-t-il des inconvénients majeurs à utiliser quelque chose comme ceci (comme la performance ou l'utilisation du processeur)?

Je sais si une valeur n'est pas valide alors elle empêchera seulement la mise à jour impliquant cette variable et les suivantes, mais toutes les données sont validées dans le code de vb.net de toute façon donc seront toujours valides lors de la soumission à la base de données , et je vais m'assurer que seules les variables où la colonne existe peuvent être soumises.

Un grand merci à l'avance,

Cordialement,

Richard Clarke

Edit:

Je sais que sur l'utilisation des chaînes SQL et le risque d'attaques par injection SQL - j'ai étudié ce un peu dans ma thèse il y a quelques semaines.

Fondamentalement, le site utilise une architecture orientée objet. Il y a beaucoup de classes - par exemple Product - qui ont plusieurs "Attributes" (j'ai créé ma propre classe Attribute, qui a des propriétés telles que DataField, Name et Value où DataField est utilisé pour obtenir ou mettre à jour des données, Name est affiché sur l'administration Le frontend lors de la création ou de la mise à jour d'un produit et la valeur qui peut être affichée sur le frontend client est définie par l'administrateur DataField est le champ que j'utiliserai dans le "UPDATE Blah SET @Field = @Value"

Je sais que c'est probablement déroutant, mais c'est vraiment compliqué à expliquer - j'ai une très bonne compréhension de l'ensemble du système dans ma tête, mais je ne peux pas le mettre en mots facilement ..

Fondamentalement, la structure est configurée de telle sorte qu'aucun utilisateur sera en mesure de changer la valeur de DataField o r Nom, mais ils peuvent changer de valeur. Je pense que si je devais utiliser des chaînes SQL paramétrées dynamiques, il n'y aurait donc pas de risque d'attaques par injection SQL.

je veux dire essentiellement boucle à travers tous les attributs de sorte qu'il finit comme:

UPDATE Products SET [Name] = '@Name', Description = '@Description', Display = @Display 

Puis boucle à travers tous les attributs encore et ajoutez les valeurs de paramètres - cela aura le même effet que l'utilisation des procédures stockées, droite?? Cela ne me dérange pas d'ajouter au temps de chargement de la page, car cela affectera principalement le frontend de l'administration, et affectera marginalement l'interface client.

+1

Oserais-je demander pourquoi vous voulez faire cela? –

+0

Je veux faire ceci afin de pouvoir ajouter des attributs, par exemple, à Product depuis l'interface d'administration. J'ai essentiellement un tableau de, par exemple, Product dans une classe "Manager" appelée ProductManager. ProductManager hérite de Manager, qui parcourt toutes les lignes de la table Products et crée une instance de Product pour chacun, avec les détails corrects, lors de sa création. Je voudrais étendre cela afin que les administrateurs aient la possibilité d'ajouter un attribut qu'ils peuvent ensuite utiliser sur l'interface client. Malheureusement cela signifie actuellement changer les sprocs à chaque fois .. – ClarkeyBoy

Répondre

2

Question 1: vous devez utiliser SQL dynamique - construire votre instruction de mise à jour comme une chaîne, et l'exécuter avec la commande EXEC.

Question 2: oui il y a - attaques par injection SQL, risque de requêtes mal formées, ajout de la nécessité de compiler une instruction SQL séparée.

+0

J'ai ajouté plus de détails, en tenant compte de cette réponse .. – ClarkeyBoy

+0

Non, vous ne pouvez pas paramétrer le SQL dynamique que vous passez à 'EXEC' –

2

Votre exemple est très inefficace, donc si je passe dans 10 colonnes, vous mettrez à jour la même table 10 fois?

La meilleure façon est de faire une mise à jour à l'aide sp_executesql et construire cette dynamique, jetez un oeil à The Curse and Blessings of Dynamic SQL pour voir comment vous devez le faire

0

Est-ce un nouveau système où vous avez la liberté de la conception si nécessaire, ou êtes-vous coincé avec un design DB existant?

Vous pouvez envisager de représenter les attributs non pas en tant que colonnes, mais en tant que lignes d'une table enfant.

Dans le parent MyObject, vous ne disposez que de données au niveau de l'en-tête, ce qui est commun à tous les objets du système (peut-être juste un identifiant). Dans la table enfant MyObjectAttribute vous auriez une clé primaire de avec une autre colonne attrValue. De cette façon, vous pouvez faire une mise à jour comme ça:

UPDATE MyObjectAttribute 
    SET attrValue = @myValue 
    WHERE objectID = @myID 
    AND attrName = @myAttrName 
+0

Je l'ai déjà considéré - mais le le système actuel en cours a besoin d'être mis à jour, ce qui nécessiterait trop de changements pour l'instant, sans risque d'erreur. Je veux dire actuellement tous les attributs sont stockés en tant que colonnes. Le système est un peu lent en ce moment - il faut environ 2 - 3 secondes sur le premier chargement de la page (presque instantané par la suite). Je pense que la mise en œuvre de votre suggestion pourrait la ralentir trop. Avez-vous déjà essayé une telle approche? Est-ce que ça marche? Est-ce efficace? Merci. Richard – ClarkeyBoy

+0

Juste pensé à autre chose, en référence à votre première phrase - essentiellement admin sera en mesure d'ajouter et de supprimer des attributs comme ils le souhaitent. Il existe certains attributs standard tels que "Créé", "Modifié" et "ID". Il y en a aussi qui ne sont applicables qu'à certains types d'objets. Mon but est que l'administrateur devrait pouvoir ajouter des champs pour des types spécifiques d'article. J'ai ajouté plus d'informations sur le site dans mon profil (y compris l'adresse du site). – ClarkeyBoy

Questions connexes