[MYSQL] Brainstorming sur la melleure structure de BDD

[Chacho]

Salut,

Je réfléchis actuellement à la mise en place d'une nouvelle rubrique pour un site et je m'interroge sur la meilleure structure de bdd possible.

Pour résumer, je vais avoir des actualités et des lieux qui pourront avoir certaines caractéristiques A,B,C etc
J'aimerais pouvoir modifier facilement la liste commune aux lieux et actualités ( et possiblement plus tard à d'autres choses ) de caractéristiques possible en rajoutant / supprimant / modifiant (le nom) une caractéristique.

J'ai une table lieux et une table actualités qui chacune contient les infos de chaque lieu/actualité tel que nom,description etc

Quel est la meilleure manière de stocker :
- la liste des caractéristiques possibles
- si chaque lieu/actualité possède ou non chaque caractéristique ?

Je réfléchis et je réfléchis mais je ne suis pas satisfait :?

Rajouter des champs A, B, C de boolean à la table actualités et la table lieux ?
Ca me semble compliqué et lourd si je veux éditer les caractéristiques..

Rajouter un champs caractéristiques à la table actualités et la table lieux avec dedans pour chaque élément les caractéristiques présentes sous la forme : A,B,C,D ?
Mais comment faire si je décide d'effacer la caractéristique B du site ?

Lol je ne m'en sors pas ! Qqun aurait une brillante idée pour moi plz ?
Chacho

 

[k2pi]

Si j ai bien compris une actualite et un lieu peuvent avoir des caracteristique commune, une actualite et un lieu pouvant avoir plusieur carateristique
Dans ce cas
Une table Actualite
Une table Lieu
une Table Caraterique
et une table d'association AssocCaracteristique (type="Lieu" ou "Actualite", id_element, id_caracteristique)

id_element correspond a l'id de l'actualite ou du lien auquel tu associe l'id de la caracteristique.

 

[Marie-Aude]

+1

 

[Chacho]

Merci k2pi ! et (Marie-Aude ) Je crois que c'est ce qu'il me faut !

 

[Malaiac]

ton explication est pas claire, mais d'apes ce que j'ai pu comprendre, une archi à la osco serait possible :
une table elements
id,name,etc.
une table options ('style','budget')
id,name
une table values ('pas cher','bon marche', 'luxueux', 'mexicain','italien','chinois')
id,name

qui seront reliés :
une table elements_options_values :
element_id,option_id,value_id

si on veut plus de solidité, une table options2values
option_id,value_id

et la table elements_options_values devient
element_id,option2value_id

 

[jarreweb]

même avis que k2pi
il est préférable d'avoir des tables avec les données listées uniques
et une table qui sert à faire la relation entre elles

c'est ce qu'il y a de plus performant et de plus souple d'utilisation

 

[k2pi]

Au passage, c'est l'architecture classique pour une relation entité n/n