juillet
2011
Un article de zinzineti
Depuis SQL SERVER 2005 la notion de schema de base de données a changé. Un schema est devenu donc un « namespace », un conteneur des objets de la base de données : Tables, Vues, Procédures, Fonctions, Triggers, Users,… Malgré cette définition claire de Microsoft on n’en voit pas la traduction dans la représentation affichée par SQL SERVER Management Studio (SSMS 2005, SSMS 2008, SSMS 2008R2). Une image est souvent plus parlant que de belles définitions…
Mettons en perspective les représentations de la notion de schema par SSMS et par RazorSQL
=> Pour une base système master vu par SSMS et RazorSQL
=> Pour une base « utilisateur » Adventureworks vu par SSMS et par RazorSQL
Avec cette représentation de schema par SSMS on comprend donc la confusion et le désordre dans l’écriture des requêtes, des procédures stockées, … désordre aussi dans l’écriture des DDLs.
Et le schema dbo (schema poubelle) est là pour qui aime le désordre et la confusion …
Je n’ai pas encore installé SQL11 (Denali), j’espère que la présentation de la notion de schema par SSMS Denali va être différente ?
=> Pour une base « utilisateur » Adventureworks vu par EMS SQL Manager
Cette présentation de la notion de schema par EMS SQL Manager (ou par SQLRazor) est plus réaliste que celle de SSMS de Microsoft.
————————————-
Etienne ZINZINDOHOUE
————————————-
Ok voici un raisonnement un peu plus cossu
Concernant les UDF tu as raisonnement … cela reste une bizarrerie SQL Server.
Je n’irai pas contre toi sur ce que propose RazorSQL. Cet utilitaire présente les choses de façon différente et peut aider à la compréhension des schémas mais j’aime également la présentation donnée par SSMS ([SCHEMA].[OBJET]) d’autant plus qu’à partir de 2008 je peux tout à faire filtrer et afficher ce que je veux (schéma, objets) … Je peux ainsi rapidement voir si j’ai 2 objets de même nom dans un schéma différent etc …
D’un côté j’ai une structure ordonnée par schéma avec pour chacun d’entre eux un dossier tables, views .. et de l’autre une structure ordonnée par type d’objet avec leurs différents schémas …
A chacune des visualisations ses avantages et ses inconvénients. La vrai amélioration pour moi serait de pouvoir définir ses préférences d’affichage et de classement
++
mikedavem : Ici je ne vois qu’une erreur de traduction dans SSMS (A corriger certainement …). On devrait plutôt avoir « diagrammes de bases de données ». Cependant ca n’explique pas vraiment les problèmes d’écriture que tu cites dans ton billet
zinzineti La présentation de la notion de schema proposée par SSMS me paraît erronée. Tu peux faire un petit test autour de toi, en montrant la présentation de SSMS à une personne qui ne connait rien en base de données et tu demandes à la personne de te proposer une définition de ce que représente un schéma. Ensuite tu reprends le test mais cette fois-ci en montrant à la même personne la présentation proposée par RazorSQL (ou EMS SQL Manager) et tu lui demandes après à quoi correspond un schema.
mikedavem :Je ne vois pas de lien direct entre cette erreur de traduction et le manque de rigueur de certains développeurs … si on peut le qualifier ainsi.
zinzineti Prenons un exemple simple.
Pour créer une fonction (UDF) le développeur peut écrire :
CREATE FUNCTION F_square_int(@valeur int)
RETURNS int
AS
BEGIN
RETURN @valeur * @valeur
END
Par contre, pour utiliser la fonction F_square_int si le développeur écrit par exemple
SELECT F_square_int(2)
Il va recevoir le message suivant
/*
Msg 195, Niveau 15, État 10, Ligne 1
‘F_square_int’ n’est pas une option nom de fonction intégrée reconnue.
*/
Pourquoi SQL SERVER n’a pas capable d’aller chercher la fonction F_square_int dans le schema dbo (qui est le schema par défaut quand ceci n’est pas explicite)?
Alors qu’à la création de la fonction F_square_int SQL Server n’a pas exigé de schema (c’est optionnel) il contraint de préciser le schema lors de l’utilisation et il faut écrire
SELECT dbo.F_square_int(2)
Pourquoi cette logique n’est pas appliquée pour la création et l’utilisation des tables, des procédures stockées,…?
C’est que j’appelle désordre et confusion
mikedavem :Il n’y a pas de différence avec Denali à ce sujet.
zinzineti Il quand même temps que la notion de schema soit mieux présenter dans SSMS… Non ? A ton avis entre la présentation proposée par EMS SQL Manager (ou par RazorSQL) et celle de SSMS, laquelle te semble plus rapproche de la définition de schema ?
Merci d’avance pour ta réponse
Ici je ne vois qu’une erreur de traduction dans SSMS (A corriger certainement …). On devrait plutôt avoir « diagrammes de bases de données ». Cependant ca n’explique pas vraiment les problèmes d’écriture que tu cites dans ton billet. Je ne vois pas de lien direct entre cette erreur de traduction et le manque de rigueur de certains développeurs … si on peut le qualifier ainsi.
Il n’appartient qu’aux développeurs de savoir ce qu’est un schéma au sens SQL du terme. Qualifier le schéma dbo de poubelle est peut être un peu fort mais cependant il est vrai que peu de personnes ou éditeurs de logiciels connaissent les avantages certains d’une telle fonctionnalité.
Il n’y a pas de différence avec Denali à ce sujet.
++