Discussion :

[Jihnn]

Salut,

Je me suis récemment rendu compte à quel point je manquais de connaissances à propos des SGBDR et du langage SQL, et j'ai tenté de remédier à la situation. Je voulais être certain d'avoir bien assimilé les différentes notions, alors je m'en remets à vous pour obtenir un peu d'aide :-)

1. Schémas
On parle quelques fois de catalogue ou de schémas. En gros, un catalogue, c'est l'équivalent des base de données et les schémas, c'est une structure qui permet de catégoriser ses tables.

1.1 - Donc un catalogue contient un ou plusieurs schémas, et chacun de ses schémas peuvent contenir une ou plusieurs tables, c'est bien ça ?
1.2 - Y a-t-il un autre avantage aux schémas, autre qu'une meilleure organisation ?

2. Index
Les index permettent d'accélérer le temps d'exécution d'une requête, comme c'est le cas pour les index dans une bibliothèque (exemple le plus récurrent).

2.1 - À quel point est-ce qu'ils accélèrent le temps d'exécution des requêtes ? Et jusqu'à quel niveau la vitesse est-elle significative (une table de plusieurs milliers de lignes, plusieurs millions, seulement une centaine ?)
2.2 - Comment sont stockés les index ? Je sais qu'ils prennent plus de place sur le disque dur, mais je comprends pas comment le SGBDR peut faire pour l'utiliser convenablement.
2.3 - Est-ce que les index sont toujours utilisés, peu importe si la requête est simple (SELECT id FROM matable), s'il y a des jointures, sous-requêtes, des vues, etc. ?

3. Primary Key
3.1 - J'ai compris deux trucs avec la contrainte Primary Key : elle est la colonne sur laquelle une Foreign Key pointe, et elle est l'équivalent des deux contraires NOT NULL et UNIQUE. Y a-t-il quelque chose d'autre à savoir sur les primary keys ? Est-ce qu'en fait, leur seul intérêt, c'est d'être la référence des FK ?
3.2 - Si on a, par exemple, les trois colonnes suivantes dans notre table membre : id, account, email. Ces trois colonnes ne peuvent être nulle et doivent être uniques, mais seulement la colonne ID va servir de référence à une foreign key dans une autre table.
Est-ce qu'on peut quand même mettre une primary key multiple sur ces trois colonnes, ou doit-on se limiter aux contraintes NOT NULL et UNIQUE sur account et email ?
3.3 - Dans le cas où la réponse à la question précédente était non, comment se servir d'une PRIMARY KEY à plusieurs colonnes ?

4- Procédures stockées
Donc, les procédures stockées, c'est l'équivalent des fonctions dans un autre langage. On peut les utiliser soit comme des fonctions, soit comme des triggers. De plus, elles sont précompilées donc plus rapides.
4.1 - Mis à part dans l'utilisation des triggers, quand peut-on les utiliser ? Je dois avouer que je ne vois pas vraiment d'autres cas.
4.2 - Est-ce vraiment l'équivalent des fonctions ?


Voilà, j'ai essayé d'organiser le tout le mieux possible, si vous avez des interrogations face à mon message, je suis prêt à y répondre :-)

Merci d'avance,

Vincent

[CinePhil]

Salut,

Je me suis récemment rendu compte à quel point je manquais de connaissances à propos des SGBDR et du langage SQL, et j'ai tenté de remédier à la situation. Je voulais être certain d'avoir bien assimilé les différentes notions, alors je m'en remets à vous pour obtenir un peu d'aide :-)

Tu trouveras beaucoup de réponses à tes questions chez SQLPro.

1. Schémas

On parle quelques fois de catalogue ou de schémas. En gros, un catalogue, c'est l'équivalent des base de données et les schémas, c'est une structure qui permet de catégoriser ses tables.

1.1 - Donc un catalogue contient un ou plusieurs schémas, et chacun de ses schémas peuvent contenir une ou plusieurs tables, c'est bien ça ?

En gros oui.
Chez MySQL, schéma = base de données. Sur un serveur, on peut faire une requête sur plusieurs bases de données, sous réserve des droits de l'utilisateur à les interroger.
Chez Postgresql, et probablement chez d'autres SGBD que je ne mâitrise pas, catalogue (ou base de données) et schéma sont deux choses distinctes.
On peut faire une requête sur plusieurs schémas à l'intérieur d'une base de données mais les bases de données sont hermétiques entre elles.

1.2 - Y a-t-il un autre avantage aux schémas, autre qu'une meilleure organisation ?

A priori comme ça et tôt le matin, rapidement, je n'en vois pas.

2. Index

Les index permettent d'accélérer le temps d'exécution d'une requête, comme c'est le cas pour les index dans une bibliothèque (exemple le plus récurrent).

2.1 - À quel point est-ce qu'ils accélèrent le temps d'exécution des requêtes ? Et jusqu'à quel niveau la vitesse est-elle significative (une table de plusieurs milliers de lignes, plusieurs millions, seulement une centaine ?)

Réponse chez SQLPro.

2.2 - Comment sont stockés les index ? Je sais qu'ils prennent plus de place sur le disque dur, mais je comprends pas comment le SGBDR peut faire pour l'utiliser convenablement.

Je crois que la réponse se trouve aussi chez SQLPro. Sinon il y a eu une discussion qui a parlé de la structure des index l'an dernier, dans laquelle SQLPro a détaillé le mécanisme. Fais une recherche dans le forum.
En gros l'optimiseur du SGBD analyse la requête et ce dont il dispose sur les tables et essaie d'utiliser l'index chaque fois que c'est possible ou que ça vaut le coup.

2.3 - Est-ce que les index sont toujours utilisés, peu importe si la requête est simple (SELECT id FROM matable), s'il y a des jointures, sous-requêtes, des vues, etc. ?

Comme j'ai dit ci-dessus, l'index est utilisé si ça vaut le coup et si c'est possible. Le SGBD les utilisera chaque fois qu'il le peut parce que ça accélère énormément ses traitements.
Pour reprendre l'image de ta bibliothèque, tu trouveras un livre par son titre si tu as un index axé sur le titre qui te dit sur quelle étagère est rangé le livre. Si tu cherches un dictionnaire et qu'il y en a peu, ce sera plus rapide d'aller directement examiner le rayon des dictionnaires pour trouver celui qui te sera utile.

3. Primary Key

3.1 - J'ai compris deux trucs avec la contrainte Primary Key : elle est la colonne sur laquelle une Foreign Key pointe, et elle est l'équivalent des deux contraires NOT NULL et UNIQUE. Y a-t-il quelque chose d'autre à savoir sur les primary keys ? Est-ce qu'en fait, leur seul intérêt, c'est d'être la référence des FK ?

Réponse chez SQLPro, je te laisse chercher.
La clé primaire est l'identifiant de la table. C'est le principal index de celle-ci.

3.2 - Si on a, par exemple, les trois colonnes suivantes dans notre table membre : id, account, email. Ces trois colonnes ne peuvent être nulle et doivent être uniques, mais seulement la colonne ID va servir de référence à une foreign key dans une autre table.
Est-ce qu'on peut quand même mettre une primary key multiple sur ces trois colonnes, ou doit-on se limiter aux contraintes NOT NULL et UNIQUE sur account et email ?

La 2ème proposition est la bonne.
Si tu mets une clé multi-colonnes, tu autorises plusieurs valeurs pour chacune des colonnes. Ainsi, deux membres pourraient avoir le même account ou le même email ou le même id ou le même couple formé par deux de ces trois colonnes.
account et email étant des index de type UNIQUE et NOT NULL sont des clés candidates mais il est effectivement meilleur d'ajouter un identifiant entier et auto-incrémenté en tant que clé primaire.
Voir chez SQLPro pourquoi.

3.3 - Dans le cas où la réponse à la question précédente était non, comment se servir d'une PRIMARY KEY à plusieurs colonnes ?

La clé primaire multi-colonnes apparaît quand la table est issue d'une association du MCD (modèle conceptuel de données, de la méthode Merise).
Exemple...
MCD :
Personne -0,n----Participer----0,n- Débat
Tables :
Personne (p_id, p_nom, p_prenom...)
Debat (d_id, d_objet...)
Participation (prt_id_personne, prt_id_debat)
Les deux colonnes prt_id_personne et prt_id_debat sont clés étrangères et forment ensemble la clé primaire de la table Participation.

4- Procédures stockées

Donc, les procédures stockées, c'est l'équivalent des fonctions dans un autre langage. On peut les utiliser soit comme des fonctions, soit comme des triggers. De plus, elles sont précompilées donc plus rapides.
4.1 - Mis à part dans l'utilisation des triggers, quand peut-on les utiliser ? Je dois avouer que je ne vois pas vraiment d'autres cas.

Bien que ne les ayant encore jamais utilisées moi-même, je crois avoir compris qu'on peut les déclencher pour faire des opération régulières telles que consolidation de données ou transfert de données anciennes dans des tables d'archivage par exemple.

4.2 - Est-ce vraiment l'équivalent des fonctions ?

Pas seulement.

[al1_24]

1.2 L'un des avantages des schémas, c'est de pouvoir déclarer des structures identiques dans des schémas différents pour des besoins de tests, développement, sauvegarde, gestion des accès concurrents (réplication périodique d'un schéma "transactionnel" qui enregistre les évènements en temps réel vers un schéma identique orienté "décisionnel" où les lourdes requêtes de consultation pourraient bloquer la mise à jour ou être faussées par des mises à jour intermédiaires)

[Jihnn]

Merci beaucoup pour les réponses !

Je connaissais le site de SQLPro (c'est là que j'avais trouvé plusieurs (excellentes) réponses), je vais continuer mes recherches.