dbo - database owner

[boby62423]

Hello,

Dans sql management studio, toutes mes tables sont préfixées par dbo. dans le listing dans la partie gauche de l'écran.
Si je fait un drag and drop sur le nom de la table pour l'utiliser dans une requête, ça me drag ce préfixe avec le nom de la table.
Sauf que si je veux executer la requete sans avoir d'erreur, je dois virer ce préfixe dbo.

C'est un peu une perte de temps...

La question que je me posais, c'est à quoi ça sert ce préfixe. Pourquoi sql management studio s'entête t il à placer cet élément devant le nom de la table systématiquement ?

D'avance merci

[iberserk]

Sauf que si je veux executer la requete sans avoir d'erreur, je dois virer ce préfixe dbo.

C'est très étrange? Avez vous des captures d'écrans?

dbo est le schéma par défaut auquel sont rattachées vos tables... vous pouvez créer plusieurs schéma pour 'grouper' vos tables par exemple.
Baser vos tables sur des schémas différents permet par exemple de gérer leurs droits directement au niveau du schéma...

[SQLpro]

Il faudrait commencer à apprendre le langage SQL !
Ce préfixe dbo est le schéma SQL par défaut de l'objet.
Tous les objets d'une base sont rangés dans des schémas SQL. Si vous ne préciser pas le schéma SQL lors du CREATE, l'objet est créé dans le schéma par défaut associé à l'utilisateur SQL qui créé l'objet.
Si lors de la création de l'utilisateur vous n'avez pas préciser de schéma par défaut, alors c'est le schéma par défaut de la base qui est utilisé.
Il n'est pas possible de créer des objets non rattaché à un schéma SQL.
Ne pas utiliser les schémas en préfixe des objets est idiot, car cela posera des problèmes de performances : le SGBDR doit rechercher quel est le schéma à utiliser dans le contexte de lancement de la requête et cela peut varier d'un utilisateur à l'autre.
Autrement dit, le serveur, en l'absence de la précision du schéma SQL et pour chaque objet, est obligé de faire une phase de résolution de nom du style :
1) quel est le schéma par défaut de l'utilisateur
2) l'objet existe t-il dans le schéma par défaut de l'utilisateur
3) si non, quel est le schéma par défaut de la base
3 ) l'objet existe t-il dans le schéma par défaut de la base.
Tout ceci prends du temps au détriment des performances...
Pire, cela oblige parfois à recompiler procédures et plan de requête !
Vous constaterez qu'il existe toujours plusieurs schémas SQL dans votre base de données (allez les voir dans l'arborescence de votre base à sécurité / schémas). Ceux en db_ sont mà pour rétrocompatibilité et vous pouvez les retirer. sys est le schéma des objets systèmes (ceux que SQL Server utilise en interne) INFORMATION_SCHEMA est la norme SQL pour les objets de méta données (vues du "catalogue").... entre autres !

Il existe d'autres avantages à utiliser des schéma SQL. Voir l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p5...es-schema-sql/

Si vous aviez lu mon livre http://sqlpro.developpez.com/booksql05/, vous auriez su cela... Extrait :
"

3.2.3.1 Le SCHEMA, ou module d'une base de données

La notion de SCHEMA permet de modulariser une base de données. En fait une base de données (donc un CATALOG selon la norme) comporte au moins un schéma dans lequel on trouvera les objets de la base (tables, vues, routines...). Comprenez qu'il n'est pas possible de créer une table directement dans le CATALOG, mais qu'il faut passer par le schéma. Ainsi une base de données peut posséder autant de SCHEMA qu'on le désire, chaque schéma pouvant correspondre à un module dans le sens que l'on donne à ce mot pour désigner une bibliothèque de code ou un espace de nom dans un langage itératif. Seule différence avec ces derniers, SQL ne permet qu'un seul niveau de schéma.

Ainsi, dans l'exemple donné ci-avant, la base de données créée comporte automatiquement un schéma. Dans MS SQL Server le schéma par défaut porte le nom dbo, c'est pourquoi à défaut de spécifier différents schéma, tous les objets créés sont préfixé par dbo pour signifier leur appartenance à ce schéma.

De fait, une base de données comporte toujours au moins un schema par défaut. Nous verrons que de manière similaire, tout utilisateur SQL est associé à un schéma par défaut qui peut être différent du schéma par défaut de la base de données.

Les avantages de la notion de SCHEMA sont considérable : outre la modularisation des objets de la base (permettant de la répartir dans différentes "unités"), le schéma permet de gérer des privilèges (autorisations) de manière souple et efficace, mais aussi de créer de toutes pièces tous les éléments d'une base de données sans que l'ordre ait une importance.
En fait un SCHEMA est un nom logique d'une subdivision d'une base de données et tout objet d'une base devrait être systématiquement préfixé par le schéma dans lequel il repose.
Notons enfin qu'un schema appartient toujours à un utilisateur, celui qui l'a créé.

Ainsi, à l'aide d'une spécification de schéma on peut commencer par créer un utilisateur et ses privilèges sur une vue qui sera créée après, vue qui elle même peut précéder la création des tables sur laquelle elle repose. Cette particularité peut paraître surprenante, mais elle possède deux avantages :
• ne pas se soucier de l'ordre de dépendance des objets, et par ce fait permettre de créer des contraintes mutuellement dépendantes;
• résoudre de fait un problème auquel se heurtent les développeurs débutants : celui de connaître l'ordre de création des tables liées par l'intégrité référentielle...

L'ordre SQL de création d'un schéma revêt la syntaxe suivante :

Code :

Le propriétaire est en fait l'utilisateur qui créé les objets dans le schéma. Un schéma a toujours un propriétaire.
La clause PATH permet de définir les schémas dans lesquels il faudra rechercher, dans l'ordre de spécification, les différentes routines à utiliser (fonctions, procédures).
...

"

Quand à vos problème personnel d'écriture des requêtes, vous vous y prenez mal. Sans doutes rajoutez vous des crochet inutiles ou d'autres éléments fantaisistes !

A +