Discussion :

[boboss123]

bonjour,

je voudrais créer les tables suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
table employé(id_employé, nom)
 
table objet(id_objet, nom, type)
	table objet_pc(id, cpu, mobo, ... )
	table objet_écran(id, résolution, contraste, ...)
 
table objet_employé(id, id_employé, id_objet)

Pouvez vous me dire quels sont les requêtes SQL que je dois effectuer pour que mes tables soient correctement créées (je ne maitrise pas bien les déclaration des clefs, contraintes, ...) ?

Remarque : les champs "nom" ne doivent pas avoir de doublon

merci d'avance,

[punkoff]

Bonjour,


Commençons donc par les bases :
http://sqlpro.developpez.com/cours/s...?page=sommaire

[boboss123]

ok merci

[boboss123]

Je suis entrain de lire le tuto. Dans le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
CREATE TABLE T_CLIENT
(CLI_NOM    CHAR(32),
 CLI_PRENOM VARCHAR(32))

Pourquoi le type de CLI_NOM n'est pas le même que celui de CLI_PRENOM ?

[punkoff]

Ce n'est qu'un exemple ne vous arrêtez pas sur ceci.

Là il montre en fait différente façon d'utiliser un create table avec des types de données SQL (INT ,CHAR, VARCHAR, ...) ou des domaines (types de données définies par l'utilisateurs), ou un mix des deux.

[boboss123]

ok, j'avais des doutes sur le fait que ça pouvait avoir des conséquence sur les performance lors des recherches

[boboss123]

Donc a priori pour créer correctement mes tables, il faut faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
CREATE TABLE employé(id_employé INT NOT NULL GENERATED ALWAYS AS IDENTITY PRIMARY KEY, nom VARCHAR(50) NOT NULL UNIQUE)
 
CREATE TABLE objet(id_objet INT NOT NULL GENERATED ALWAYS AS IDENTITY PRIMARY KEY, nom VARCHAR(50) NOT NULL UNIQUE, type VARCHAR(10))
	CREATE TABLE objet_pc(id_pc INT NOT NULL GENERATED ALWAYS AS IDENTITY PRIMARY KEY, cpu, mobo, ... , id_objet INT NOT NULL UNIQUE FOREIGN KEY REFERENCES objet(id_objet))
	CREATE TABLE objet_écran(id_écran INT NOT NULL GENERATED ALWAYS AS IDENTITY PRIMARY KEY, résolution VARCHAR(10), contraste VARCHAR(10), ..., id_objet INT NOT NULL UNIQUE FOREIGN KEY REFERENCES objet(id_objet))
 
CREATE TABLE objet_employé(id_obj_emp INT NOT NULL GENERATED ALWAYS AS IDENTITY PRIMARY KEY, id_employé INT NOT NULL FOREIGN KEY REFERENCES employé(id_employé), id_objet INT NOT NULL FOREIGN KEY REFERENCES objet(id_objet))

- la table employé liste les employés
- la table objet liste tous les objets
- la table objet_pc liste tous les objets de type pc (contient les attributs spécifiques aux pc)
- la table objet_écran liste tous les objets de type écran (contient les attributs spécifiques aux écrans)
- la table objet_employé liste tous les objets que possède chaque employé

c'est bon , je n'ai pas fait de boulettes (j'ai un doute sur la strcture de ma bdd et les déclaration des clefs étrangères) ?

[punkoff]

Concernant la modélisation en elle même je ne pourrai pas vous aider.

Essayer d'étayer votre besoin une autre personne vous aidera surement.

[boboss123]

mon besoin est de pouvoir dans ma bdd
- lister tous les employés
- lister tous les pc (ou rechercher un pc en fonction de son nom) et afficher leur paramètres : nom, cpu, mobo
- lister tous les écrans (ou rechercher un écran en fonction de son nom) et afficher leur paramètres : nom, résolution, contraste
- lister tous les objets qui appartiennent un certain employé et afficher les paramètres des objets en fonctions du type de celui-ci

[SQLpro]

ok, j'avais des doutes sur le fait que ça pouvait avoir des conséquence sur les performance lors des recherches

Oui, cela en a !

A +

[boboss123]

Oui, cela en a !

A +

est-ce que tu pourrais développer stp ?

[SQLpro]

CHAR(n) => respecte de la longueur dont n caractères stockée même si la longueur du texte est inférieure à n, il y aura alors un remplissage à blanc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Exemple "toto" en CHAR(12) donne "toto        "

VARCHAR(n) => longueur variable avec au maximum n caractères stockée + stockage de la longueur du texte (e général sur 2 octets) et pas de remplissage à blanc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Exemple "toto" en VARCHAR(12) donne 04"toto"

AVANTAGES / INCONVÉNIENTS :
VARCHAR économise de l'espace si la longueur des données peut être grande et la taille du texte très fluctuante. Or l'espace économisé se sont des performances en plus.
Mais si la données est voisine de la taille max ou fais toujours la taille max, alors avec les 2 octets pour stocker la taille c'est le contraire qui se produit.
Par exemple pour un code postale, c'est stupide car il y aura toujours 5 caractères (en France) => VARCHAR = 7 octets, CHAR = 5 octets

En sus, la recherche d'une colonne VARCHAR est plus complexe que la recherche d'une colonne chat au sein de la ligne composant la table. Son accès est donc plus lent, car il faut parcourir toutes les colonnes précédentes du fait de la longueur variable.

Enfin, lors des mises à jour la fragmentation du VARCHAR peut devenir très pénalisante. En effet si j'ai stocké "toto" dans un VARCHAR(16) qui va être enchâssé dans la ligne, comment puis-je le faire passer à "taratata" dans une UPDATE ? Il n'est plus possible de la laisser à cet emplacement qui est trop court. Il va donc falloir déplacer soit la ligne complète (si la table n'est pas clusterisée) soit la colonne si la table est clusterisée, et dans tous les cas cela génère de la fragmentation qui est très préjudiciable aux performances.

C'est pourquoi lorsque l'on modélise des données, il faut étudier les types de données avec soin, en sachant quels vont être les traitements, la volumétrie...

J'ai fait une entrée de mon blog en sus sur le sujet :
http://blog.developpez.com/sqlpro/p9...el-difference/

A +

[boboss123]

ok merci pour ta réponse c'est très bien expliqué

Et pour la structure de ma table vous feriez comme ça ?

[Waldar]

À noter que ce n'est pas vrai pour tous les SGBD.
Chez Oracle, il ne vaut mieux pas utiliser les CHAR, qui sont en fait des VARCHAR2 complétés par des blancs et qui stockent également la longueur de la colonne.

Pour traduire le grand gourou :

n'utilisez pas le type CHAR qui ne va engendrer que de la confusion, faites comme s'il n'existait pas

Pour ce point :

Enfin, lors des mises à jour la fragmentation du VARCHAR peut devenir très pénalisante. En effet si j'ai stocké "toto" dans un VARCHAR(16) qui va être enchâssé dans la ligne, comment puis-je le faire passer à "taratata" dans une UPDATE ?

Heureusement une partie des blocks est laissée libre pour ce genre de mises à jour, ça couvrira la très grande majorité des cas simples.

[SQLpro]

...
Heureusement une partie des blocks est laissée libre pour ce genre de mises à jour, ça couvrira la très grande majorité des cas simples.

Ce n'est valable que si vous avez prévu un FILL FACTOR (ou PCTFREE sous Oracle qui fait toujours cavalier seul, y compris sur les chars....)

A +