MS SQL Server
  1. MS SQL Server
  3. Les relations SQL Server sont noyées dans des procédures stockées plutôt que dans des schémas
Intereting Posts
Violation de contrainte SqlException Comment contourner la partition de sql-server au maximum? Comment faire un webservice et connectez-vous à l'application android mettre à jour une colonne de la table dans le server de sql de l'access de milliseconde Requête SQL WHERE sur une plage de dates Conflit de collation Exécuter xp_create_subdir sans les privilèges d'administration Utilisez SMO pour modifier les locations par défaut de la database SQL Server Pourquoi Visual Studio 2008 ne créera-t-il pas de files .mdf avec SQL Server 2008 Developer installé? Combinaison de deux instruction select dans where clause Impossible d'exécuter la procédure stockée synonyme avec le pilote ODBC SQL Server; fonctionne avec OLEDB SQL Server, sélectionnant parmi 2 colonnes de tables différentes Colonne calculée persistante avec sous-requête Création d'un numéro week_ref à transmettre dans une procédure stockée System.InvalidCastException: impossible de convertir la valeur de paramètre d'un XElement en une string

Les relations SQL Server sont noyées dans des procédures stockées plutôt que dans des schémas

À l'heure actuelle, nous avons très peu d'intégrité référentielle, de même qu'un certain nombre de tables qui s'auto-rejoignent (et qui seraient peut-être mieux représentées en tant que tables ou vues séparées).

La connaissance de la relation entre ces tables est implicite dans la logique des procédures stockées plutôt qu'explicite dans le schéma. Nous envisageons de changer cela.

La première étape consiste à comprendre réellement les relations implicites et à les documenter.

Donc ma question est …

Quelle est la meilleure façon d'extraire cette information implicite, à court de regarder toutes les procédures stockées. Je considérerai tous les outils, écrire mon propre SQL pour interroger les tables système, ou utiliser le model SQL-DMO – ou en fait tout ce qui est sous le soleil qui permet à l'ordinateur de faire plus de travail et de faire less.

Si les relations ne sont identifiées que par des jointures dans les SP, alors vous n'aurez pas beaucoup de chance à l'automatiser.

Il peut être utile de capturer des requêtes en utilisant le profileur pour find les jointures les plus fréquentes en premier.

Quand il s'agit de refactoring, je suis la vieille école:

  1. Documentez ce que vous avez, utilisez un outil visuel.
  2. Décrivez – par écrit – le model de gestion que cette database capture.
  3. Sélectionnez les entités parmi les noms de description et le schéma existant.
  4. Créer un nouveau model ER; consulter avec les entresockets tout en elle.
  5. Créer une nouvelle database basée sur l'urgence
  6. Données ETL sur la nouvelle database et test.

Vous pouvez utiliser sys.sql_dependencies pour connaître les colonnes et les tables dont dépend un SP (cela vous aide si vous ne faites SELECT * dans vos SP). Cela vous aidera à get un inventaire des candidats au less: 

 referenced_major_id == the OBJECT_ID of the table referenced_minor_id == the column id: COLUMNPROPERTY(referenced_major_id, COLUMN_NAME, 'ColumnId')

Vous devrez peut-être utiliser sp_refreshsqlmodule pour vous assurer que les dependencies sont à jour pour que cela fonctionne. Par exemple, si vous modifiez une vue, vous devez sp_refreshsqlmodule sur chaque module non lié au schéma (les modules liés au schéma ne permettent évidemment pas de changements sous-jacents – mais vous obtiendrez une erreur si vous appelez sp_refreshsqlmodule sur un object lié au schéma) qui dépendait de cette vue. Vous pouvez automatiser cela en appelant sp_refreshsqlmodule sur ces objects: 

 SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE OBJECTPROPERTY(OBJECT_ID(QUOTENAME(ROUTINE_SCHEMA) + '.' + QUOTENAME(ROUTINE_NAME)), N'IsSchemaBound') IS NULL OR OBJECTPROPERTY(OBJECT_ID(QUOTENAME(ROUTINE_SCHEMA) + '.' + QUOTENAME(ROUTINE_NAME)), N'IsSchemaBound') = 0