créer trois procédures stockées (sélectionner/mettre à jour/insérer) par table ou selon les besoins?

en utilisant asp.net, SQL Server 2008, WinServer2003créer trois procédures stockées (sélectionner/mettre à jour/insérer) par table ou selon les besoins?

nous avons environ 10 tables avec 20 champs chacun ...

nous avons environ 30 formulaires Web où chaque forme utilise une certaine variation des champs de certains/toutes les tables ...

Chaque formulaire possède son propre ensemble de données en fonction des tables qu'il utilise. Toutefois, pour créer cet ensemble de données, une procédure stockée Select * est appelée sur chaque table utilisée. Le jeu de données est mis à jour via le formulaire/code et une procédure stockée générique Insert ou Update est appelée par datatable, en passant chaque champ en paramètre. Bien que pléthorique, il existe seulement 3 procédures stockées par table qui sont utilisées par tous les formulaires, ce qui équivaut à 30 procédures stockées totales.

Est-il préférable de créer des procédures stockées Select/Update/Insert personnalisées pour chaque formulaire en utilisant uniquement les champs dont le formulaire a besoin ... soit un total de 90 procédures stockées? Ce nombre pourrait augmenter à mesure que les formulaires augmentent ...

Source

2009-12-01 eych

Voulez-vous profiter ce que dit psasik, je beleive que Sql programmeurs devrait être plus donner à l'acceptation. Ce fil a eu 30 vues (à l'époque) avec les votes de ZERo ... X- ( –

a répondu à mes questions et a accepté les réponses qui m'ont été utiles.) – eych

Les procédures stockées ont-elles des fonctionnalités spéciales ou exécutent-elles uniquement des instructions de base codées en dur telles que "SELECT * FROM table"?

Si elles exécutent simplement des instructions de base, il est probablement préférable de se débarrasser des procédures stockées et d'utiliser SQL dynamique. Cela réduira la quantité de travail de maintenance que vous avez à faire. Les anciens problèmes de performances avec le SQL dynamique ne sont plus pertinents, car les systèmes de mise en cache et de compilation de SQL Server sont tellement meilleurs maintenant. Les problèmes de sécurité sont également obsolètes, car vous pouvez utiliser le paramétrage dans les requêtes dynamiques maintenant.

Source

2009-12-01 19:22:53

même si vous créez une insertion dynamique avec des paramètres [par exemple "Insérer dans les clients (Nom, Ville) Valeurs (@pName, @ pCity) ] puis ajoutez les paramètres ["cmd.Paramters.Ajouter (new SqlParameter ("@ CustomerId", System.Data.SqlDbType.Int)) "], n'avez-vous pas encore besoin de déclarer les variables du paramètre en haut? – eych

Cela dépend de la langue/framework que vous utilisez. exemple ressemble à C#/ADO.NET Dans ce cas, ADO.NET déclare les paramètres pour vous lorsque vous les ajoutez à la collection Parameters de la commande.Note: les noms de paramètre dans votre requête doivent correspondre aux noms dans la collection Parameters. votre code devrait ressembler à ceci: SQL: Insérez en clients (Nom, Ville) Valeurs (@pName, @ pCity) C#: cmd.Parameters.AddWithValue ("@ PName", "John Doe"); cmd .Parameters.AddWithValue ("@ pCity", "Baltimore"); Le type de données n'est généralement pas nécessaire pour les paramètres. –

Est-il vraiment nécessaire d'utiliser le SP pour cela, ou pourriez-vous plutôt utiliser des requêtes paramétrées? Cela évitera la croissance des fournisseurs de services et réduira le trafic du serveur pour les champs qui ne sont pas requis par formulaire.

Utilisez des requêtes spécialisées pour exécuter les instructions select, insert et update, plutôt qu'un SP général pour les faire à partir de plusieurs formulaires.

Source

2009-12-01 19:17:26

astander, vérifiez mon commentaire à Josh. Vous dites utiliser des requêtes paramétrées spécialisées, mais Vous n'avez pas besoin de déclarer chaque paramètre avec son type avant d'appeler la requête? Pouvez-vous déclarer dynamiquement les paramètres? – eych

Vous pouvez ajouter des paramètres en spécifiant simplement le nom et la valeur SqlCommand cmd = new SqlCommand(); cmd.Parameters .Add ("nom", valeur); Dans VS 2008, ils veulent que vous utilisiez Parameters.AddWithValue –

Vous devriez reconsidérer la mise en œuvre des concepts de logique biz si étroitement entre votre interface utilisateur et votre base de données. Vous et votre équipe devez revenir en arrière pour analyser les types d'objets métier dont votre système a besoin plutôt que de les mapper sur le grand nombre d'écrans. Vous pouvez avoir des SP CRUD par objet biz mais beaucoup de vos objets d'affichage doivent être manipulés par une poignée de vue (à moins que votre modèle ne soit complètement loufoque.)

Source

2009-12-01 19:26:55

Si vous avez vraiment besoin d'un SP (sécurité?) Alors vous devriez au moins envisager d'utiliser Merge. Avec Merge, vous obtenez une commande intégrée upsert.

"Upsert, quoi?":

update myTable set [email protected], [email protected] where [email protected] 
if @@rowcount = 0 
insert into myTable (Col1, Col2) values (@col1, @col2)

Source

2009-12-01 19:32:00

créer trois procédures stockées (sélectionner/mettre à jour/insérer) par table ou selon les besoins?

Répondre

Questions connexes