Aide modélisation BDD

Bonjour,
J'aimerais avoir de l'aide sur la modélisation d'une partie de ma bdd.
J'ai un site web qui permet a des clients de louer des serveurs : 3 offres mutualisés, 3 offres VPS et et 4 offres SeedBox.

Ma question est :
Faut t'il que je fasse 1 table Services qui contient toutes les offres avec le prix, le type de service (1: Mutualisé, 2: VPS, 3: Seedbox) et les caractéristiques de chaque offres ? Le problème c'est que la colonne Processeur, on en a pas besoin pour la Seedbox, donc ce seras a nul.
Ou alors, faire 3 tables pour les 3 services.

Je penche plus pour la première mais vu que je ne suis pas très expérimenté en structure de BDD, je préfère demandé.
Merci d'avance.

Bonjour,

Le choix de la solution dépend du nombre d'attributs spécifiques et de la répartition (peut être qu'un service est beaucoup plus fréquent que d'autres)

Un héritage me parait intéressant dans ce cas...
À me lire : http://sqlpro.developpez.com/cours/m...tion/heritage/

a +

Bonjour,
merci pour vos réponses.
Un héritage ? Je ne savais pas que c'était possible en bdd :D Je vais voir ca merci :)

Salut à tous.

Citation:

---

Envoyé par asurion

J'ai un site web qui permet a des clients de louer des serveurs : 3 offres mutualisés, 3 offres VPS et et 4 offres SeedBox.

---

D'emblée, vous avez trois types d'entités qui sont :
--> offres mutualisées.
--> offres VPS.
--> offres SeedBox.

Chaque entité aura ses propres caractéristiques et aussi des caractéristiques communes.
Afin d'éviter toutes redondances d'informations au sein de votre base de données, vous devez créer une entité dite commune (offre), contenant comme le nom l'indique, ce qui est commun à vos trois entités.
Eviter aussi d'avoir des colonnes dont le marqueur est à NULL.

Ne pas oublier non plus, l'entité client qui peut aussi posséder plusieurs offres.

Soit au total six tables, qui vont se répartir ainsi :
--> une table client, avec une clef unique pour chaque client.
--> une table commune (offre), qui reprend la partie commune à toutes vos offres. Il y a aussi une clef unique pour toutes vos offres.
--> une table associative, qui va faire le lien entre le client et toutes les offres qu'ils possèdent.
Dans la plupart des cas, un client possède une seule offre.

Ensuite nos trois tables :
--> une pour l'offre mutualisée
--> une pour l'offre VPS
--> une pour l'offre SeedBox
On accède à ces tables avec la clef de la table commune (offre).

Je vous communique un exemple sous MySql :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263

-------------- SET AUTOCOMMIT = 0 --------------   -------------- START TRANSACTION --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- DROP TABLE IF EXISTS `client` --------------   -------------- CREATE TABLE `client` ( `id_client` integer unsigned not null auto_increment primary key, `nom` varchar(255) not null, `prenom` varchar(255) not null, `adresse` varchar(255) not null, `postal` varchar(255) not null, `ville` varchar(255) not null ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `client` (`nom`,`prenom`,`adresse`,`postal`,`ville`) values ('Daudet', 'Alphonse', '15 boulevard Raspail', '75006', 'Paris'), ('Blum', 'Léon', '33 rue de la Gaité', '75014', 'Paris') --------------   -------------- select * from client --------------   +-----------+--------+----------+----------------------+--------+-------+ | id_client | nom | prenom | adresse | postal | ville | +-----------+--------+----------+----------------------+--------+-------+ | 1 | Daudet | Alphonse | 15 boulevard Raspail | 75006 | Paris | | 2 | Blum | Léon | 33 rue de la Gaité | 75014 | Paris | +-----------+--------+----------+----------------------+--------+-------+ -------------- DROP TABLE IF EXISTS `offre` --------------   -------------- CREATE TABLE `offre` ( `id_offre` integer unsigned not null auto_increment primary key, `detail` varchar(255) not null ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `offre` (`id_offre`,`detail`) values (10,'Mutualisé N°1'),(11,'Mutualisé N°2'),(12,'Mutualisé N°3'), (20,'VPS N°1'), (21,'VPS N°2'), (22,'VPS N°3'), (30,'SeedBox N°1'), (31,'SeedBox N°2'), (32,'SeedBox N°3'), (33,'SeedBox N°4') --------------   -------------- select * from offre --------------   +----------+---------------+ | id_offre | detail | +----------+---------------+ | 10 | Mutualisé N°1 | | 11 | Mutualisé N°2 | | 12 | Mutualisé N°3 | | 20 | VPS N°1 | | 21 | VPS N°2 | | 22 | VPS N°3 | | 30 | SeedBox N°1 | | 31 | SeedBox N°2 | | 32 | SeedBox N°3 | | 33 | SeedBox N°4 | +----------+---------------+ -------------- DROP TABLE IF EXISTS `mutualise` --------------   -------------- CREATE TABLE `mutualise` ( `id_mutualise` integer unsigned not null primary key, `capacite` varchar(255) not null, CONSTRAINT `FK_MUTUALISE` FOREIGN KEY (`id_mutualise`) REFERENCES `offre` (`id_offre`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `mutualise` (`id_mutualise`,`capacite`) values (10, 'détail capacité mutualisé N°1'), (11, 'détail capacité mutualisé N°2'), (12, 'détail capacité mutualisé N°3') --------------   -------------- select * from mutualise --------------   +--------------+-------------------------------+ | id_mutualise | capacite | +--------------+-------------------------------+ | 10 | détail capacité mutualisé N°1 | | 11 | détail capacité mutualisé N°2 | | 12 | détail capacité mutualisé N°3 | +--------------+-------------------------------+ -------------- DROP TABLE IF EXISTS `vps` --------------   -------------- CREATE TABLE `vps` ( `id_vps` integer unsigned not null primary key, `processeur` varchar(255) not null, CONSTRAINT `FK_VPS` FOREIGN KEY (`id_vps`) REFERENCES `offre` (`id_offre`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `vps` (`id_vps`,`processeur`) values (20, 'détail processeur VPS N°1'), (21, 'détail processeur VPS N°2'), (22, 'détail processeur VPS N°3') --------------   -------------- select * from vps --------------   +--------+---------------------------+ | id_vps | processeur | +--------+---------------------------+ | 20 | détail processeur VPS N°1 | | 21 | détail processeur VPS N°2 | | 22 | détail processeur VPS N°3 | +--------+---------------------------+ -------------- DROP TABLE IF EXISTS `seedbox` --------------   -------------- CREATE TABLE `seedbox` ( `id_seedbox` integer unsigned not null primary key, `cloud` varchar(255) not null, CONSTRAINT `FK_seedbox` FOREIGN KEY (`id_seedbox`) REFERENCES `offre` (`id_offre`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `seedbox` (`id_seedbox`,`cloud`) values (30, 'détail cloud seedbox N°1'), (31, 'détail cloud seedbox N°2'), (32, 'détail cloud seedbox N°3') --------------   -------------- select * from seedbox --------------   +------------+--------------------------+ | id_seedbox | cloud | +------------+--------------------------+ | 30 | détail cloud seedbox N°1 | | 31 | détail cloud seedbox N°2 | | 32 | détail cloud seedbox N°3 | +------------+--------------------------+ -------------- DROP TABLE IF EXISTS `associative` --------------   -------------- CREATE TABLE `associative` ( `id_associative` integer unsigned not null auto_increment primary key, `id_client` integer unsigned not null, `id_offre` integer unsigned not null, `inscription` date not null, CONSTRAINT `FK_associative_client` FOREIGN KEY (`id_client`) REFERENCES `client` (`id_client`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_associative_offre` FOREIGN KEY (`id_offre`) REFERENCES `offre` (`id_offre`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- insert into `associative` (`id_client`,`id_offre`,`inscription`) values (1, 21, '2015-07-14'), (2, 12, '2015-09-23'), (2, 32, '2015-07-25') --------------   -------------- select * from associative --------------   +----------------+-----------+----------+-------------+ | id_associative | id_client | id_offre | inscription | +----------------+-----------+----------+-------------+ | 1 | 1 | 21 | 2015-07-14 | | 2 | 2 | 12 | 2015-09-23 | | 3 | 2 | 32 | 2015-07-25 | +----------------+-----------+----------+-------------+ -------------- select c.id_client, c.nom, c.prenom, a.id_offre, m.capacite, v.processeur, s.cloud   from associative as a   inner join client as c on a.id_client = c.id_client   inner join offre as o on o.id_offre = a.id_offre   left outer join mutualise as m on m.id_mutualise = a.id_offre   left outer join vps as v on v.id_vps = a.id_offre   left outer join seedbox as s on s.id_seedbox = a.id_offre --------------   +-----------+--------+----------+----------+-------------------------------+---------------------------+--------------------------+ | id_client | nom | prenom | id_offre | capacite | processeur | cloud | +-----------+--------+----------+----------+-------------------------------+---------------------------+--------------------------+ | 1 | Daudet | Alphonse | 21 | NULL | détail processeur VPS N°2 | NULL | | 2 | Blum | Léon | 12 | détail capacité mutualisé N°3 | NULL | NULL | | 2 | Blum | Léon | 32 | NULL | NULL | détail cloud seedbox N°3 | +-----------+--------+----------+----------+-------------------------------+---------------------------+--------------------------+ -------------- COMMIT --------------   -------------- SET AUTOCOMMIT = 1 --------------   Appuyez sur une touche pour continuer...

---

C'est l'idée de base ! A vous d'enrichir cette base de données à votre convenance.

@+

Merci pour vos réponses :)
@Artemus24, j'ai repris ton modèle, mais le problème c'est comment je peux savoir si la personne possède des VPS, ou avoir la liste uniquement des VPS ?
Je peux faire des where nom = "VPS OFFRE1" and nom = 'VPS OFFRE2", ... mais c'est pas très propre :D
Tu penses que je peux ajouter une colonne offretype ? 1 pour vps par exemple.

EDIT:
Ma requête qui permet de récuperer les informations d'un service (avant la commande, le paiement) :

Code:

---

1 2 3 4 5

SELECT o_id, o_type, o_prix, o_disque, os_bp, os_streaming, ov_cpu, ov_cpu_hz, ov_ram from hs_offres left join hs_offres_mutualise using (o_id) left join hs_offres_seedbox using (o_id) left join hs_offres_vps using (o_id) where o_libelle = ? LIMIT 1

---

Mais le problème c'est que j'ai une page /ORDER/PERSO-VPS (PERSO-VPS = o_libelle dans la requête) et donc je dois afficher les informations relatives a cette offre.
Je ne peux pas mettre une information a NULL dans les informations, donc je dois faire plein de if else pour voir si c'est null ou pas, pas très propre non ?

Merci encore pour votre aide !

Faites une vue et rajoutez dans votre vue un CASE indiquant la nature de la branche d'héritage.

D'autre part utiliser la jointure naturelle avec USING est la pire des connerie, mais en matière de crétinisme MySQmerde en est pas à sa première !!! A lire : https://blog.developpez.com/sqlpro/p...oudre_aux_yeux

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

CREATE VIEW V_offres AS SELECT O.*, CASE WHEN OM.o_id IS NOT NULL THEN 'Mutuallisé' WHEN OS.o_id IS NOT NULL THEN 'Seedbox' WHEN OV.o_id IS NOT NULL THEN 'VPS' END AS OFFRE_TYPE, ... FROM hs_offres AS O LEFT OUTER JOIN hs_offres_mutualise AS OM ON O.o_id = OM.o_id LEFT OUTER JOIN hs_offres_seedbox AS OS ON O.o_id = OS.o_id LEFT OUTER JOIN hs_offres_vps AS OV ON P.o_id = OV.o_id;

---

À vous de compléter les ... par les colonnes qui vont bien des branches d'héritage.

A +

Merci beaucoup :) Je vais voir cela.
ahah on dirait mon ancien prof de base de données qui jurer que par Oracle et n'aimer pas MySQL :D

Salut à tous.

C'est à vous d'enrichir vos tables afin de répondre à vos besoin, ce qui n"a pas été spécifié dès le départ dans votre premier message.
Je vous rappelle que mon exemple est une ébauche basée sur la notion d'héritage de SQLPRO et demande à être perfectionné.

Citation:

---

Envoyé par asurion

le problème c'est comment je peux savoir si la personne possède des VPS, ou avoir la liste uniquement des VPS ?

---

La solution consiste à partie de la table VPS et de remonter jusqu'au client :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

-------------- select *   from vps as v   left outer join associative as a on a.id_offre = v.id_vps   left outer join offre as o on o.id_offre = a.id_offre   left outer join client as c on c.id_client = a.id_client --------------   +--------+---------------------------+----------------+-----------+----------+-------------+----------+---------+-----------+--------+----------+----------------------+--------+-------+ | id_vps | processeur | id_associative | id_client | id_offre | inscription | id_offre | detail | id_client | nom | prenom | adresse | postal | ville | +--------+---------------------------+----------------+-----------+----------+-------------+----------+---------+-----------+--------+----------+----------------------+--------+-------+ | 21 | détail processeur VPS N°2 | 1 | 1 | 21 | 2015-07-14 | 21 | VPS N°2 | 1 | Daudet | Alphonse | 15 boulevard Raspail | 75006 | Paris | | 20 | détail processeur VPS N°1 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | | 22 | détail processeur VPS N°3 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | +--------+---------------------------+----------------+-----------+----------+-------------+----------+---------+-----------+--------+----------+----------------------+--------+-------+

---

Dans cette exemple, vous avez uniquement la liste des offres VPS.
Il y aura autant de ligne id_vps=21 qu'il y a de clients.

Citation:

---

Envoyé par asurion

Tu penses que je peux ajouter une colonne offretype ? 1 pour vps par exemple.

---

Dans votre exemple, il n'est pas utile de surcharger la modélisation avec ce genre de colonne dans la table offre.

Citation:

---

Envoyé par asurion

Je ne peux pas mettre une information a NULL

---

Vous commencez à saloper le modèle par héritage.
Ce modèle est fait pour répondre à deux problèmes :
--> celui d'éviter la répétition d'informations dans plusieurs tables.
--> celui d'éviter de mettre des NULL dans les colonnes.

Donc non, ce n'est pas une bonne idée de procéder ainsi et pour répondre à quel besoin ?

Citation:

---

Envoyé par asurion

je dois afficher les informations relatives a cette offre.

---

Si l'offre est par exemple "mutualisé", comme dans le cas des "VPS", vous devez commencer par cette table et remonter jusqu'au client :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

-------------- select *   from mutualise as m   left outer join associative as a on a.id_offre = m.id_mutualise   left outer join offre as o on o.id_offre = a.id_offre   left outer join client as c on c.id_client = a.id_client --------------   +--------------+-------------------------------+----------------+-----------+----------+-------------+----------+---------------+-----------+------+--------+--------------------+--------+-------+ | id_mutualise | capacite | id_associative | id_client | id_offre | inscription | id_offre | detail | id_client | nom | prenom | adresse | postal | ville | +--------------+-------------------------------+----------------+-----------+----------+-------------+----------+---------------+-----------+------+--------+--------------------+--------+-------+ | 12 | détail capacité mutualisé N°3 | 2 | 2 | 12 | 2015-09-23 | 12 | Mutualisé N°3 | 2 | Blum | Léon | 33 rue de la Gaité | 75014 | Paris | | 10 | détail capacité mutualisé N°1 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | | 11 | détail capacité mutualisé N°2 | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | +--------------+-------------------------------+----------------+-----------+----------+-------------+----------+---------------+-----------+------+--------+--------------------+--------+-------+

---

Il y aura autant de ligne id_mutualise= 12 qu'il y a de clients.

Citation:

---

Envoyé par asurion

je dois faire plein de if else pour voir si c'est null ou pas, pas très propre non ?

---

Non, car votre problème est que vous raisonnez mal.
Quand vous voulez extraire quelque chose d'une base de données, partez toujours du plus spécifique au plus général.
Dans les deux exemples ci-dessus, vous recherchez les offres VPS ou Mutualisé, et bien, la première table sera ou VPS ou Mutualisé.
Si vous ne désirez pas les NULL dans le résultat final, le mieux est de remplacer "left outer join" par "inner join".

@ SQLPRO : il n'est pas nécessaire de créer une view car ce que demande asurion, c'est une extraction en partant d'une des trois tables, à savoir Mutualisé, VPS ou SeedBox.

Citation:

---

Envoyé par asurion

ahah on dirait mon ancien prof de base de données qui jurer que par Oracle et n'aimer pas MySQL

---

Et ça sert à quoi d'avoir un préjugé ?
A démontrer l'insuffisance de ce professeur dans le domaine des bases de données, et à ne pas savoir se remettre en question, non ?
Et si Oracle vient à disparaître, que va-t-il dire ou faire ?
Cela en dit long sur le niveau intellectuel de votre professeur, asurion !

On stoppe les querelles de clochers qui n'ont pas lieu d'être dans ce forum. :evilred:

@+

Citation:

---

Envoyé par asurion

Merci beaucoup :) Je vais voir cela.
ahah on dirait mon ancien prof de base de données qui jurer que par Oracle et n'aimer pas MySQL :D

---

Tout simplement parce que MySQL n'est absolument pas un SGBD Relationnel ! Ce n'est pas parce que c'est marqué SQL dessus que c'est relationnel ! Déjà en 1985, Franck Edgar Codd (le fondateur des SGBDR) appelait l'attention des professionnels sur les produits soi-disant relationnels qui ne l'était en réalité pas, et pour cela édicta les 12 règles de Codd. Sur 12, MySQL en viole au moins 4 !
Ce qui fait que certaines requêtes sont impossible à faire dans MySQL.
Lisez cet article : https://blog.developpez.com/sqlpro/p...bd_relationn_1
Et vous verrez que ni PostGreSQL ni MySQmerde ne sont des SGDB relationnels !



A +

:salut:
Il te sied pour ton cas d'utiliser les jointures pour faire des requetes multitables...!
Mais tout depend du développeur à l'autre, moi je puis mettre les tout dans un ltems d'une listebox ou une liste déroulante au sein des balises form et input. Ou carement partir avec d'une analyse fonctionnelle ou une narration pouvant servir à ressortir d'abord les entités et également faire une étude minutieuse de besoins attendus afin d'avoir les differents champs pour chaque entité.
Bref, fais toi un petit cahier de charges et partir de ce cahier à la modelisation sur base de la complexité de besoins, delais, materiels à utiliser et competance à concretiser les taches.....

Parce qu'à t'entendre, c'est le problème de champs???