Bonjour,
 
J'ai besoin d'un petit conseil/avis avant que je me lance...
 
Je vais faire un annuaire de sites persos.
Les sites seront classés selon leurs contenus (blog, fonds d'écrans, port folio...).
Evidemment un site perso peut avoir plusieurs contenus (par ex. des fonds et un port folio)...
 
Alors je pense faire une table avec :
 
Id - nom du site - url - fonds - portfolio - blog - etc.
 
Après je rentrerais les sites genre :
 
1 - Le site de Julia - http://www.xyz.com - 0 - 1 - 1 - etc.
 
0 = ne contient pas cela, 1 = présence de ça sur le site
 
Pour la recherche l'utilisateur précisera s'il cherche par ex. un port folio et tous les sites avec 1 dans la partie port-folio seront affichés...
 
 
 
Est ce une bonne "stratégie" ? La moins compliquée ? La plus efficace ?
 
Merci de vos commentaires...

oui

 
  simple précis merci

 
Tres mauvaise idee !
 
Qu'est ce qui se passe si tu compte ajouter des catégories? Tu vas devori chaque fois modifier ton script et ajouter des champs. Pas tres pratique,
 
tu devrais faire comme ceci :  
 
 

 
dans la table site le champ id categorie tu le met en char pour qu'il puisse contenir des caractere. Pourquoi? c'est simple , si tu as plusieur categories pour un site ton champ IdCategorie va contenir ceci :
 

 
par exemple ce qui correspond aux ID des categories ou tu souhaite qu'il apparaisse.
 
lorsque tu va clickez sur une categorie dans ton site, tu fais une requete SQL avec un LIKE sur le champ IdCategorie, si le ID de la categories en cours est trouvé dans ce champ tu affiche sinon pas.
 
Voila a+

 
ah d'accord ... ouf j'allais commencer aujourd'hui
 
Bon merci beaucoup, c'est vrai qu'à priori je n'aurais pas de catégorie à ajouter mais il vaut mieux être prudent !
 
Merci bcp Schtroumpheur !!!

     
C'est, disons, original comme méthode  
tu fais des comparaisons entre des entiers et des chaînes de caractères  
 
Et il se passe quoi quand tu atteints les 10 catégories ???
 
Pour être a peu près dans la logique SQL, il faudrait une table intermédiaire qui fasse le lien entre les sites et les catégories.
| IdSite | IdContenu |
 
Pour chaque site, il y aura une entrée dans cette table pour chaque contenu du site.
Pour éviter une table pas forcément indispensable, tu peux considérer que IdContenu ne pointe pas vers une table mais que tu traites directement la valeur dans ton code.

mrbebert a écrit a écrit :         C'est, disons, original comme méthode   tu fais des comparaisons entre des entiers et des chaînes de caractères     Et il se passe quoi quand tu atteints les 10 catégories ???   Pour être a peu près dans la logique SQL, il faudrait une table intermédiaire qui fasse le lien entre les sites et les catégories. | IdSite | IdContenu |   Pour chaque site, il y aura une entrée dans cette table pour chaque contenu du site. Pour éviter une table pas forcément indispensable, tu peux considérer que IdContenu ne pointe pas vers une table mais que tu traites directement la valeur dans ton code.

 
euh alors là je suis tout embrouillé
 
je vois pas ce que tu veux dire... Si je traite directement la valeur dans mon code c'est un peu comme si je rajoutais un champ IdContenu à ma table principale (avec le nom du site, son url...) non ?

thekeke2 a écrit a écrit :     euh alors là je suis tout embrouillé   je vois pas ce que tu veux dire... Si je traite directement la valeur dans mon code c'est un peu comme si je rajoutais un champ IdContenu à ma table principale (avec le nom du site, son url...) non ?

non, car tu peux en avoir plusieurs pour chaque site.
Si tu as une entrée d'Id 1 dans la table des sites, tu pourras avoir, par exemple, les entrées (1, 1), (1, 7), (1, 8) dans la deuxième table, pour indiquer que le site 1 à les contenus 1, 7 et 8.
Ces valeurs 1, 7 et 8 peuvent être des identifiants dans une table des contenus, ou bien des valeurs que tu traites directement dans ton code.

 
ok mais c'est pas un peu "compliqué" pour un simple annuaire d'avoir 3 tables comme ça ?
En clair : c'est la seule solution ?
 
Ca me gène pas, loin de là, mais bon je pensais que ça alait être plus simple... Parce que là rien que pour l'admin quand tu ajouteras un site ca devra ecrire dans 2 tables dont une plusieurs fois de suite... C est plus de boulot de ce coté là aussi...

thekeke2 a écrit a écrit :     ok mais c'est pas un peu "compliqué" pour un simple annuaire d'avoir 3 tables comme ça ? En clair : c'est la seule solution ?   Ca me gène pas, loin de là, mais bon je pensais que ça alait être plus simple... Parce que là rien que pour l'admin quand tu ajouteras un site ca devra ecrire dans 2 tables dont une plusieurs fois de suite... C est plus de boulot de ce coté là aussi...

non, pas forcément. Surtout que la deuxième table contient des enregistrement de petite taille, de longueur fixe (pas de champs varchar ou text). Ca se manipule assez bien.
 
Si tu veux vraiment optimiser, tu peux utiliser des masques binaires. Tu mets un champ entier dans la table des sites, et du positionne les bits qui vont bien. Ca revient à regrouper les différents champs booléens que tu avais dans ton premier post dans un seul entier.
Par exemple, pour les valeurs 0, 4 et 7, tu y mettras l'entier 145 (2^7 + 2^4 + 2^0). C'est certainement plus performant, mais  moins pratique à utiliser.
 
Mais ta solution initiale n'est pas si mal, si tu considères que tu n'auras que rarement à ajouter des types de contenu.

mrbebert a écrit a écrit :

 
cette methode marche tres bien , je ne vois absolument pas ce qui te choque, tu as une liste des id des catégories ou doit se trouver le site, et il faut bien un caractère autre qu'un chiffre pour distinguer une separation entre, ou est le prob?
 
Et il se passe quoi quand tu atteints les 10 catégories ??? il peut y en a voir 100 cela ne change rien du tout justement .

 
par contre si tu veux changer une catégorie pour un site tu es obligé de rouvrir le code genre 4 - 6 - 8 - 10 pour retirer "manuellement" la rub 6 par ex ?

 
  un bon informaticien prevois toujorus ce genre de situation.

 
A toi de creer le script qui gere cela, a priori ce n'est pas tres difficile avec toute les fonctions qui existe deja dans php, je cite: explode(), implode(), str_replace, regexp() et j'en passe... y a moyen de s'en sortir en 10 lignes pas plus.

thekeke2 a écrit a écrit :     ok mais c'est pas un peu "compliqué" pour un simple annuaire d'avoir 3 tables comme ça ? En clair : c'est la seule solution ?   Ca me gène pas, loin de là, mais bon je pensais que ça alait être plus simple... Parce que là rien que pour l'admin quand tu ajouteras un site ca devra ecrire dans 2 tables dont une plusieurs fois de suite... C est plus de boulot de ce coté là aussi...

Si tu suis ma methode, le script admin n'aura a ecrire que dans UNE et UNE seule table. La table "sites".

Si tu recherche la catégorie 1 en faisant un Like, y a des chances pour qu'il te ramène les 10, 11 ...
Et si tu veux les sites qui ont 2 catégories particulières ?
Passer par des chaînes de caractères pour traiter des entiers, c'est à la fois une source d'erreurs, de complications et une perte de performances.
 
Quand à modifier la structure d'une table, n'exagérons rien, ca se fait. Faut pas que ce soit en permanence, mais si tu ajoutes une colonne tous les 2 mois, ca n'est pas un problème.

Dans ton LIKE tu peux preciser que il doit obligatoirement avoir un "-" avant et un "-" apres ce que tu cherches et donc ca evite le bug que tu me cite.
 
Si tu fais LIKE '%$idcategorie%' ca va poser des probleme ca c'est évident
 
pour la syntaxe exacte du LIKE je ne la connais pas par coeur, il faut que me renseigne mais une chose est sur il y a moyen de le faire... 2 minute je cherche

D'accord avec la solution de mrbebert : il faut essayer de respecter le modèle entité-relation.
 
Ce n'est pas pour compliquer par plaisir, mais c'est effectivement le meilleur moyen de répondre facilement à des évolutions futures.
 
Donc pour résumer : 3 tables, une table SITE, une table CONTENU et une table de liaison SITE_CONTENU, avec les structures suivantes :
 
SITE : Id_Site, Nom_site, Url
 
CONTENU : Id_Contenu, Description_contenu
 
SITE_CONTENU : Id_Site, Id_Contenu
 
Ainsi tu pourras facilement associer plusieurs contenus à un site, et rajouter ultérieurement d'autres types de contenus dans la table CONTENU sans pour autant avoir à modifier la structure de ta base.
 
En ce qui concerne les requêtes, tu auras au plus 2 jointures à faire.

ah vous me mettez en plein doute

 
Cette solution n'est en effet pas mauvaise, mais il faut une table en plus et donc la base de donnée sera plus grande, mais je n'ai jamais dit que sa solution etait mauvaise, je defendais juste la mienne...
 
edit: par contre devoir chaque fois ajouter un champ booleen dans la table je trouve que ce n'est pas une bonne idee, autant que l'annuaire soit bien construit directement.  

 
Euh la base de données plus grande ? Ok tu auras quelques Ko en plus lors de la création, en revanche tu te retrouves avec une structure relationnelle standard qui est beaucoup plus souple et maintenable.
 
Quant à ta solution, elle est certes mieux que celle initiale avec la table unique, mais dans un schéma de base de données relationnelle, il est plus prudent de n'avoir qu'une seule info par intersection champ / ligne.
En effet dans ton cas tu concatènes des données de code numériques comme faisait remarquer mrbebert, et c'est gênant dans le cas d'utilisation de l'instruction LIKE '1%' par exemple, qui ramènera non seulement '1' mais aussi '11'.
 
Certes tu as des fonctions en php qui te permettent peut-être de rattraper le coup, mais dans ce cas tu ne te sers pas des fonctionnalités du SGBD . Autant avoir une architecture correcte dès le départ , non ? Et s'éviter ainsi l'obligation de gérer les cas tendancieux en php ...

irulan a écrit a écrit :     Euh la base de données plus grande ? Ok tu auras quelques Ko en plus lors de la création, en revanche tu te retrouves avec une structure relationnelle standard qui est beaucoup plus souple et maintenable.   Quant à ta solution, elle est certes mieux que celle initiale avec la table unique, mais dans un schéma de base de données relationnelle, il est plus prudent de n'avoir qu'une seule info par intersection champ / ligne. En effet dans ton cas tu concatènes des données de code numériques comme faisait remarquer mrbebert, et c'est gênant dans le cas d'utilisation de l'instruction LIKE '1%' par exemple, qui ramènera non seulement '1' mais aussi '11'.   Certes tu as des fonctions en php qui te permettent peut-être de rattraper le coup, mais dans ce cas tu ne te sers pas des fonctionnalités du SGBD . Autant avoir une architecture correcte dès le départ , non ? Et s'éviter ainsi l'obligation de gérer les cas tendancieux en php ...

 
Ton explication me satisfait.
Mais bon jusqu'a aujourd'hui je pensais que c'etait la meilleure facon de faire. Bon ben j'irais me coucher moins con ce soir. A+

yen a ki se complik la vie pr rien ... pour son truc une simple table suffit comme il le dit

 
<soupir>
Bon tu es sûr que tu as lu en détail le topic ?
Non parce que là j'en ai un peu marre d'argumenter.
 
Donc pour résumer : OUI une simple table suffit pour faire LA requête dont thekeke2 parlait, mais NON si tu vois un poil plus loin que le bout de ton clavier
 
C'est une base destinée à un annuaire de sites web, qui par définition sera amené à évoluer (du moins je crois).
Toute la discussion (superflue selon toi, mais bon) avait pour but de démontrer qu'avec un minimum d'effeort et de réflexion, tu pouvais avoir une structure de base beaucoup plus fonctionnelle et maintenable.

irulan a écrit a écrit :     <soupir> Bon tu es sûr que tu as lu en détail le topic ? Non parce que là j'en ai un peu marre d'argumenter.   Donc pour résumer : OUI une simple table suffit pour faire LA requête dont thekeke2 parlait, mais NON si tu vois un poil plus loin que le bout de ton clavier   C'est une base destinée à un annuaire de sites web, qui par définition sera amené à évoluer (du moins je crois). Toute la discussion (superflue selon toi, mais bon) avait pour but de démontrer qu'avec un minimum d'effeort et de réflexion, tu pouvais avoir une structure de base beaucoup plus fonctionnelle et maintenable.

 
euh oui c'est bien que ma solution marche mais en effet si je peux faire un truc plus "correcte" sans trop me casser la tête je suis preneur (sans aller trop loin non plus)...
 
Donc bah merci pour vos explications... je vais essayer le coup des trois Tables et puis si je panique je reviendrais à ma solution 1  

si tu maitrise pas les jointures, laisse beton, reste a ton systeme d'une table

 
C'est une bonne occasion d'apprendre non ? (c'est pas un début trop dur ?)

oui/non