Mélanger carottes et navets ?

[Sarc]

Bonjour à tous,

Sur le mur de Facebook, il y a un peu de tout... Des statuts, des vidéos, des réponses à des questionnaires, des scores de jeux, etc.

A votre avis, comment c'est structuré dans la base de données ?

J'hésite entre deux structures complètement différentes :

Une table pour chaque objet différent (une pour les statuts, une pour les scores aux jeux, une pour les vidéos, etc...). Le script va aller chercher dans la totalité des tables, puis afficher le tout. Mais comment faire alors la gestion des commentaires pour chaque objet ?

Tenter de regrouper tous les objets dans la même table (mais comment faire ? Chacune a ses variables différentes...). Mais là cette fois, il est facile de sélectionner tous les objets, vu que ça ne sort que d'une table. Et il est facile de gérer les commentaires, vu qu'on a créé un sur-objet de tous les objets différents.

J'aimerais votre avis pour avoir la meilleure implémentation. Les deux idées au dessus me déplaisent... Mais je sais pas vraiment comment mieux faire.

[Tchinkatchuk]

Ce que tu veux correspond apparremment au modèle EAV.

Des entités (video, news, commentaires, ...) auxquelles sont "attachés" des attributs (titre, video_file, status ...)

En espérant t'avoir guider un minimum

[captain_torche]

En ce qui concerne les commentaires, dans la première option, il suffit de faire une clé sur deux champs : id de la cible, et type de la cible.

[paolodelmare]

La bd facebook c'est pas du sql (cassandra), donc la structure est pas forcément transposable

T'as un slide ici

[Sarc]

Merci pour vos réponses !

@Tchinkatchuk : Après une recherche (j'avoue rapide), je vois qu'il est difficile de trouver des cours sur ce modèle... Tu saurais où en trouver ? J'aimerais bien lire à ce sujet.

@Captain : c'est vrai que je peux faire comme ça. Non, ce qui me gêne le plus, c'est l'affichage. Si je crée une table par type d'objet, je vais devoir faire de multiples selects (parce que le nombre de colonnes sera sûrement différent), puis les retrier par date via PHP, puis en faire un traitement spécifique pour l'affichage. Avec la deuxième solution, le problème est justement de mélanger de tout dans une même table, dont des objets qui n'auront pas nécessairement le même nombre d'attributs.

Bref, je suis coincé au niveau de la structure : soit j'ai un truc très propre mais dur à mettre en place, soit j'ai un truc moche mais fonctionnel.

@paolodelmare : Merci pour la ressource et pour l'information. Après un rapide coup d'il, je vais attendre de ne plus être le matin pour comprendre les slides, ça m'a l'air bien poussé.

[Tchinkatchuk]

Merci pour vos réponses !

@Tchinkatchuk : Après une recherche (j'avoue rapide), je vois qu'il est difficile de trouver des cours sur ce modèle... Tu saurais où en trouver ? J'aimerais bien lire à ce sujet.

@Captain : c'est vrai que je peux faire comme ça. Non, ce qui me gêne le plus, c'est l'affichage. Si je crée une table par type d'objet, je vais devoir faire de multiples selects (parce que le nombre de colonnes sera sûrement différent), puis les retrier par date via PHP, puis en faire un traitement spécifique pour l'affichage. Avec la deuxième solution, le problème est justement de mélanger de tout dans une même table, dont des objets qui n'auront pas nécessairement le même nombre d'attributs.

Bref, je suis coincé au niveau de la structure : soit j'ai un truc très propre mais dur à mettre en place, soit j'ai un truc moche mais fonctionnel.

@paolodelmare : Merci pour la ressource et pour l'information. Après un rapide coup d'il, je vais attendre de ne plus être le matin pour comprendre les slides, ça m'a l'air bien poussé.

Je n'en ai pas sous la main malheureusement.

J'ai appris à la dure (donc pas forcément la meilleur méthode ) en regardant la base de données de Magento.

Mais une fois assimilé, on a l'impression d'avoir beaucoup plus de possibilités lors de la conception technique.