Stockage des requêtes SQL dans Table sur le serveur SQL

Nous avons plusieurs tâches dans notre système. Ces travaux sont répertoriés dans une grille. Nous avons 3 types d'utilisateurs différents (usertypeid 1,2,3). Pour chaque liste d'utilisateurs est différent et il peut filtrer la liste en sélectionnant vue à partir d'une liste déroulante. ViewName dans le tableau ci-dessous est la vue qui doit être affichée. Pour réaliser cette fonctionnalité, un autre développeur a créé la structure de table suivante et stocké des fragments sql dans SQLExpression dans le tableau ci-dessous. Selon moi, la requête ne devrait pas être stockée dans la base de données. Quels sont les avantages et les inconvénients de cette approche et quelles sont les alternatives disponibles?Stockage des requêtes SQL dans Table sur le serveur SQL

JobListingViewID   ViewName  SQLExpression   UserTypeID 
3      All Jobs   1 = 1      3 
4      Error Jobs JobStatusID IN (2)    1 
5      Error Jobs JobStatusID IN (2)    2 
6      Error Jobs JobStatusID IN (2)    3 
7      Speech  JobStatusID IN (1, 3, 8)   1

Source

2010-05-26 Rohit

Pourquoi n'utilisez-vous pas la fonctionnalité intégrée SQL Agent Jobs? Pourquoi réinventer la roue? –

Vous ne savez pas que c'est quelque chose à voir avec SQL Agent? Peut-être un système de planification du travail. (emplois pour le client) –

Nous obtenons un fichier de dictée de médecins et de créer un emploi à partir de celui-ci. – Rohit

Vous avez juste besoin d'avoir une table de matrice de ViewNameUserTypeIDJobStatusID combinaisons puis rejoindre sur que dans votre requête. Vous n'avez pas besoin de SQL dynamique et d'une recherche DB supplémentaire. NB: Pour la vue "Tous les travaux" vous devriez avoir une requête différente qui renonce à la JOIN. Cela permettra d'économiser un peu de traitement inutile et signifie que lorsque vous ajoutez un nouveau travail, vous n'avez pas à configurer les autorisations. Pour le reste, utilisez une matrice comme ci-dessous.

 
ViewName  JobStatusID  UserTypeID 
Error Jobs    2    1 
Error Jobs    2    2 
Error Jobs    2    3 
Speech     1    1 
Speech     3    1 
Speech     8    1

Source

2010-05-26 06:26:25

Inconvénients: 1. Douleur à maintenir. 2. Aucune optimisation (mise en cache, etc.). 3. La modification des noms d'objets signifie que vous devrez modifier les données de cette table. C'est bon pour les quelques enregistrements, mais une fois que la table se développe, vous passerez plus de temps à maintenir cette table.

Source

2010-05-26 06:44:34

+1 Mettez-vous d'accord sur les points 1 et 3. Il mettrait également en cache le plan de requête pour le SQL dynamique. @Rohit pour renverser la tendance Qu'est-ce que votre collègue dit les avantages de leur approche? –

Il dit que ses données prédéfinies.Alors je l'ai stocké de cette façon. Il y a des statuts prédéfinis pour un travail dans system.Ces changements ne changeront pas, donc whynot stocke ces identifiants et les utilise comme clause where. – Rohit

À droite, on dirait qu'il n'y a pas de bonne raison de le faire. En termes de pourquoi pas. La performance, la maintenance, l'ajout de complexité inutile viennent immédiatement à l'esprit. De plus, si vous les avez stockés dans la base de données de manière traditionnelle, il est beaucoup plus simple de créer un écran d'administration pour configurer les permissions ou les utiliser dans d'autres requêtes. –

Je suppose que le développeur est correct, et cette approche, si elle fonctionne pour lui (et pour le reste du système) est aussi bonne que n'importe quel autre. Retouchez-le plus tard si cela pose un problème - performances, maintenance, quelque chose ...

Source

2010-05-26 07:05:08

Pas du tout d'accord. Il y a une manière standard de faire ceci en SQL si vous partez de là alors je suggérerais que le fardeau de la preuve est sur vous pour avoir une bonne raison pourquoi. –

Stockage des requêtes SQL dans Table sur le serveur SQL

Répondre

Questions connexes