SQL Server 2005: enveloppement des tables par vues – Avantages et inconvénients

Context

Je travaille sur un système d'automation de petites entresockets (inventaire, ventes, approvisionnement, etc.) qui a une database unique hébergée par SQL Server 2005 et un tas d'applications client. Le client principal (utilisé par tous les users) est une application MS Access 2003 (ADP), et d'autres clients incluent diverses applications VB / VBA comme les compléments Excel et les utilitaires de command line.

En plus d'une soixantaine de tables (la plupart du time en 3NF), la database contient environ 200 vues, environ 170 UDF (pour la plupart des scalaires et des tables en ligne) et environ 50 procédures stockées. Comme vous l'avez peut-être deviné, une partie de ce que l'on appelle la «logique métier» est encapsulée dans cette masse de code T-SQL (et est donc partagée par tous les clients).

Dans l'set, le code du système (y compris le code T-SQL) n'est pas très bien organisé et résiste très bien au refactoring, pour ainsi dire. En particulier, les schémas de la plupart des arrays réclament toutes sortes de refactorings, petits (comme les renommages de colonnes) et grands (comme la normalisation).

FWIW, j'ai une expérience de développement d'applications assez longue et décente (C / C ++, Java, VB, et autres), mais je ne suis pas un DBA. Donc, si la question vous semble stupide, vous savez maintenant pourquoi. 🙂

Question

En pensant à refactoriser tout ce gâchis (d'une manière pacifique bien sûr), j'ai trouvé l'idée suivante:

Pour chaque table, créez une vue "wrapper" qui (a) a toutes les colonnes que la table a; et (b) dans certains cas, a des colonnes calculées supplémentaires basées sur les colonnes "réelles" de la table.

Un exemple typique (bien que simplist) d'une telle colonne calculée additionnelle serait le prix de vente d'un produit dérivé du prix et de la remise réguliers du produit.
Réorganiser tout le code (code client T-SQL et VB / VBA) afin que seules les vues "wrapper" se réfèrent directement aux tables.

Ainsi, par exemple, même si une application ou une procédure stockée devait insert / mettre à jour / supprimer des loggings d'une table, ils le feraient par rapport à la vue "wrapper de table" correspondante, et non directement à la table.

Donc, essentiellement, il s'agit d' isoler toutes les tables par des vues du rest du système .

Cette approche semble apporter beaucoup d'avantages, notamment du sharepoint vue de la maintenabilité. Par exemple:

Lorsqu'une colonne de table doit être renommée, cela peut être fait sans réécrire tout le code client affecté en une fois.
Il est plus facile d'implémenter des attributes dérivés (plus facile que d'utiliser des colonnes calculées).
Vous pouvez effectivement avoir des alias pour les noms de colonnes.

Évidemment, il doit y avoir un prix pour tous ces avantages, mais je ne suis pas sûr que je vois toutes les sockets qui se cachent là-bas.

Quelqu'un at-il essayé cette approche dans la pratique? Quels sont les principaux pièges?

Un inconvénient évident est le coût de la maintenance des vues "wrapper" en synchronisation avec leurs tables correspondantes (une nouvelle colonne dans une table doit également être ajoutée à une vue, une colonne supprimée d'une table doit également être supprimée de la vue, etc. .). Mais ce prix semble être petit et équitable pour rendre le code global plus résilient.

Est-ce que quelqu'un connaît d'autres inconvénients, plus forts?

Par exemple, l'utilisation de toutes ces vues "wrapper" au lieu de tables est très susceptible d'avoir un impact négatif sur les performances, mais cet impact sera-t-il suffisamment important pour s'en préoccuper? En outre, lors de l'utilisation de ADODB, il est très facile d'get un jeu d'loggings qui ne peut pas être mis à jour même s'il est basé uniquement sur quelques tables jointes; Alors, les vues "wrapper" vont-elles aggraver les choses? Et ainsi de suite…

Tous les commentaires (en particulier une expérience réelle partagée) seraient grandement appréciés.

Je vous remercie!

PS Je suis intervenu sur l'ancien article suivant qui traite de l'idée des vues "wrapper":

Le mythe de la grande vue

L'article conseille d'éviter l'approche décrite ci-dessus. Mais … je ne vois pas vraiment de bonnes raisons contre cette idée dans l'article. Bien au contraire, dans sa list de bonnes raisons de créer une vue, presque chaque élément est exactement pourquoi il est si tentant de créer une vue "wrapper" pour chaque table (en particulier dans un système hérité, dans le cadre du process de refactoring ).

L'article est vraiment vieux (1999), donc toutes les raisons étaient bonnes alors peut-être ne sont plus bonnes maintenant (et vice versa). Il serait vraiment intéressant d'entendre quelqu'un qui a examiné ou même essayé cette idée récemment, avec les dernières versions de SQL Server et MS Access …

Lors de la design d'une database, je préfère ce qui suit:

pas d'access direct à la table par le code (mais cela est acceptable pour les procédures stockées et les vues et fonctions)
une vue de base pour chaque table qui comprend toutes les colonnes
une vue étendue pour chaque table incluant des colonnes de search (types, états, etc.)
procédures stockées pour toutes les mises à jour
fonctions pour toutes les requêtes complexes

ceci permet au DBA de travailler directement avec la table (append des colonnes, nettoyer des choses, injecter des données, etc.) sans perturber la base de code, et il isole la base de code de toute modification apscope à la table (temporaire ou autre)

il peut y avoir des pénalités de performance pour faire les choses de cette façon, mais jusqu'à présent, ils n'ont pas été significatifs – et les avantages de la couche d'isolation ont été des sauveteurs à plusieurs resockets

Vous ne remarquerez aucun impact sur les performances pour les vues à table unique. SQL Server utilisera la table sous-jacente lors de la construction des plans d'exécution pour tout code utilisant ces vues. Je vous recommand de schématiser ces vues, pour éviter de changer accidentellement la table sous-jacente sans changer la vue (pensez au pauvre gars suivant).

Quand une colonne de table doit être renommée

Dans mon expérience, cela arrive rarement. L'ajout de colonnes, la suppression de colonnes, le changement d'index et le changement de types de données sont les scripts habituels que vous allez exécuter.

Il est plus facile d'implémenter des attributes dérivés (plus facile que d'utiliser des colonnes calculées).

Je le contesterais. Quelle est la différence entre mettre le calcul dans une définition de colonne et le mettre dans une définition de vue? En outre, vous verrez un hit de performance pour le déplacer dans une vue au lieu d'une colonne calculée. Le seul véritable avantage est que la modification du calcul est plus facile dans une vue que par la modification d'une table (en raison d'index et de pages de données).

Vous pouvez effectivement avoir des alias pour les noms de colonnes.

C'est la vraie raison d'avoir des vues; aliasing tables et colonnes, et en combinant plusieurs tables. La meilleure pratique dans mes derniers emplois a été d'utiliser des vues où je devais dénormaliser datatables (searchs et autres, comme vous l'avez déjà souligné).

Comme d'habitude, la réponse la plus véridique à une question de DBA est "ça dépend" – de votre situation, compétences, etc. Dans votre cas, refactoring "tout" va briser toutes les applications de toute façon. Si vous corrigez correctement les tables de base, l'indirection que vous essayez d'get à partir de vos vues ne sera pas nécessaire et ne doublera la maintenance de votre schéma que pour les modifications futures. Je dirais sauter les vues wrapper, réparer les tables et les procédures stockées (qui fournissent déjà assez d'informations se cachant), et tout ira bien.

Je suis d'accord avec le commentaire de Steven – principalement parce que vous utilisez Access. Il est extrêmement important de garder les avantages / inconvénients d'Access au centre de la design de cette database. J'ai été là, fait avec le back-end d'access frontal / SQL Server (même si ce n'était pas un projet ADP).

J'appendais que les vues sont bonnes pour s'assurer que datatables ne sont pas modifiées en dehors des formulaires d'access dans le projet. L'inconvénient est que les procédures stockées sont requirejses pour toutes les mises à jour – si vous ne les avez pas déjà, elles doivent également être créées.