Les plages de dates dans les vues - est-ce normal?

Question

J'ai récemment commencé à travailler dans une entreprise avec un énorme "entreprise". application. Lors de mon dernier travail, j'avais conçu la base de données, mais nous avons ici tout un département d'architecture de base de données dont je ne fais pas partie.

L’un des éléments étranges de leur base de données est qu’ils disposent de nombreuses vues qui, au lieu de demander à l’utilisateur de fournir les plages de dates qu’elles souhaitent voir, se joignent à une table (globale temporaire) "TMP_PARM_RANG". avec une date de début et de fin. Chaque fois que l'application principale commence à traiter une demande, la première chose à faire est de la faire " SUPPRIMER DE TMP_PARM_RANG ;" puis un insert dedans.

Cela semble être une manière bizarre de faire les choses, mais pas très sûre, mais tout le monde ici semble bien. Est-ce normal ou mon malaise est-il valide?

Mise à jour Je dois mentionner qu'ils utilisent des transactions et des verrous par client, ce qui le met à l'abri de la plupart des problèmes de simultanéité. En outre, il existe littéralement des dizaines, voire des centaines de vues, qui dépendent toutes de TMP_PARM_RANG .

Answer 1

Est-ce que je comprends bien?

Il existe une vue comme celle-ci:

SELECT * FROM some_table, tmp_parm_rang
  WHERE some_table.date_column BETWEEN tmp_parm_rang.start_date AND tmp_parm_rang.end_date;

Ensuite, dans certaines interfaces, un utilisateur entre une plage de dates et l’application effectue les opérations suivantes:

1. Supprime toutes les lignes existantes de TMP_PARM_RANG
2. insère une nouvelle ligne dans     TMP_PARM_RANG avec les valeurs de l'utilisateur
3. sélectionne toutes les lignes de la vue

Je me demande si les modifications apportées à TMP_PARM_RANG sont validées ou restaurées et, dans l'affirmative, quand? Est-ce une table temporaire ou une table normale? Fondamentalement, selon les réponses à ces questions, le processus peut ne pas être exécuté en toute sécurité par plusieurs utilisateurs. On espère que si cela avait été le cas, ils l'auraient déjà découvert et résolu, mais qui sait?

Même si cela se fait de manière thread-safe, modifier la base de données pour de simples opérations de requête n'a pas beaucoup de sens. Ces DELETE et INSERT génèrent des redo / undo (ou l’équivalent dans une base de données non Oracle), ce qui est complètement inutile.

Un moyen simple et plus normal d'atteindre le même objectif serait d'exécuter cette requête, en liant les entrées de l'utilisateur aux paramètres de la requête:

SELECT * FROM some_table WHERE some_table.date_column BETWEEN ? AND ?;

Answer 2

Si la base de données est Oracle, il s’agit peut-être d’une table temporaire globale; chaque session voit sa propre version de la table et les insertions / suppressions n'affectent pas les autres utilisateurs.

Answer 3

Il doit exister une raison d’affaires pour ce tableau. J'ai vu des vues avec des dates codées en dur qui étaient en fait une vue partitionnée et qui utilisaient des dates comme champ de partitionnement. J'ai également vu rejoindre une table comme lorsque face à l'heure avancée, imaginez une vue qui restitue toute l'activité qui s'est produite pendant l'heure d'été. Et aucune de ces choses ne serait effacer et insérer dans la table ... c'est juste étrange

Donc, soit il y a une raison plus profonde à rechercher, soit c'est quelque chose qui, à l'époque, semblait être une bonne idée, mais la raison pour laquelle cela a été fait a été perdu comme connaissance tribale.

Answer 4

Personnellement, je suppose que ce serait un événement assez étrange. Et de ce que vous dites, deux méthodes appelant le processus en même temps pourraient être très intéressantes.

Généralement, les plages de dates sont définies en tant que filtres dans une vue et ne dépendent pas des valeurs extérieures stockées dans d'autres tables.

La seule justification que j'ai pu voir est qu'il y avait un processus en plusieurs étapes, qui n'était exécuté qu'une fois à la fois et que les dates étaient nécessaires pour plusieurs opérations, à travers plusieurs procédures stockées.

Answer 5

Je suppose que cela leur permettrait de prendre en charge plusieurs gammes. Par exemple, ils peuvent renvoyer toutes les dates comprises entre le 1/1/2008 et le 1/1/2009 ET les 1/1/2006 et 1/1/2007 pour comparer les données de 2006 aux données de 2008. Vous ne pouvez pas faire cela avec une seule paire de paramètres liés. De plus, je ne sais pas comment Oracle met en cache sa planification de requête pour les vues, mais cela a peut-être quelque chose à voir avec cela? Lorsque les colonnes de date sont vérifiées dans la vue, le serveur peut mettre en cache un plan qui suppose toujours que les dates seront vérifiées.

Jeter quelques suppositions ici:)

Vous avez également écrit:

  

Je devrais mentionner qu'ils utilisent   transactions et verrous par client, donc   il est gardé contre la plupart des concurrents   problèmes.

Bien que cela puisse protéger contre les problèmes de cohérence des données dus à la simultanéité, les problèmes de performances dus à la simultanéité font mal.

Answer 6

Ont-ils également ajouté un - dans l'application - pour générer la prochaine valeur unique pour la clé primaire?

Il semble que le concept d'état partagé échappe à ces gens, ou que la raison de l'état partagé nous échappe.

Answer 7

Cela me semble être un algorithme assez étrange. Je me demande comment il gère la concurrence - est-il emballé dans une transaction?

Il me semble que quelqu'un n'était pas sûr de savoir comment écrire sa clause WHERE.

Answer 8

Les vues sont probablement utilisées comme tables temporaires. Dans SQL Server, nous pouvons utiliser une variable de table ou une table temporaire (# / ##) à cette fin. Bien que les experts ne recommandent pas de créer des vues, j'en ai créé beaucoup pour mes projets SSRS car les tables sur lesquelles je travaille ne font pas référence les unes aux autres (NO FK's, sérieusement!). Je dois contourner les lacunes de la conception de la base de données; c'est pourquoi j'utilise beaucoup les vues.

Answer 9

L’approche GTT par la table temporaire globale que vous commentez étant utilisée ici, la méthode est certainement sûre par rapport à un système multi-utilisateur, donc pas de problème. Si c’est Oracle, je voudrais vérifier que le système utilise un niveau approprié d’échantillonnage dynamique pour que le GTT soit correctement joint, ou qu’un appel à DBMS_STATS soit effectué pour fournir des statistiques sur le GTT.