Discussion :

[fredtheman]

Bonjour,

Comme je n'ai pas trouvé de post avec les mot-clés "nombre items variable", je me permets de poser la question.

Je débute dans le domaine des bases de données, et me demandais quelle est la méthode recommandée pour gérer les cas où un dossier possède une partie dont le nombre d'occurence est variable. Par exemple, un livre peut avoir un ou plusieurs auteurs.

Je pensais à priori faire une colonne "auteurs" qui serait en fait une chaîne qui contiendrait un ou plusieur auteurs délimités par un séparateur, du genre:
sAuteurs = "john doe#jane doe#bo doe"
INSERT into livre VALUES (NULL,sAuteurs)

Est-ce la méthode orthodoxe et recommandée de gérer ce cas de figure, ou est-il recommandé de plutôt créer une table indépendante afin de pouvoir indexer par exemple?

Merci pour tte info
Fred.

[qi130]

La méthode "bien comme il faut" veut qu'une table Auteur existe afin de pouvoir établir une relation entre un livre et son (ses) auteur(s).
Cela permet en outre:
1/ de travailler en sélection sans avoir besoin de tripatouiller la chaine avec les #{@ ou autre délimiteur
2/ donc de faire bosser le SGBD pour connaitre les auteurs d'un bouquin (il va s'appuyer sur ses index, donc ça ira très vite)
3/ qu'un auteur écrive plusieurs livres et que son nom ne figure qu'une fois dans la BD

[sinarf]

Bonjour,

Dans le cas dont tu parles il faut que tu gères une relation de plusieurs à plusieurs.

[fredtheman]

Merci ts les deux pour l'info :-) Je vais faire des tests de perf avec les deux solutions, et voir si ça fait une différence. En fait, cette colonne contenant plusieurs items combinés n'a pas besoin d'être indexé ni recherchée via un LIKE. C'est pourquoi je voulais voir si c'était vraiment nécessaire de créer une table-relation.

Thx
Fred.

[laffreuxthomas]

Laisse tomber les perfs, arrête la bidouille et fais une base normalisée. Tu n'es pas seul au monde et il faut penser à ceux qui reprendront ton travail plus tard, aussi.