Salut,

J'ai un petit problème de conception et dont je ne suis pas sûr du raisonement.

J'ai repris un projet d'il y a quelques mois que j'avais abandonné par manque d'idée.

J'ai notamment des méthodes qui imbriquent plusieurs requetes. Au départ je passais les 3 requetes en paramètres mais c'était vraiment pas le top, et puis je me suis dit pourquoi ne pas faire des attribut genre $fields, $where etc ? La requete est plus facilement modulable (exemple si la requete du dessous à besoin du résultat de la requete du dessus), et bingo ça marche, impec !

Cependant une question me trotte dans la tête et j'ai du mal à voir si je vois juste ou pas du tout:

Si je veux utiliser ce système là partout, je suis obligé à chaque fois de répéter les même attributs dans mes différentes classes, or je trouve ça extrêmement redondant et mal conçu.

Donc mon idée était de faire une classe SQL utilisable par toutes les autres classes (car toutes les autres classes vont utiliser des requêtes SQL), d'après le peu que je connais de la POO pour qu'une classe, méthode etc soit accesible sans devoir l'instancier c'est le mot clé static qu'il faut utiliser.

Ainsi je n'aurais pas à devoir répéter les attributs dans chaque classe, mais il y aurait donc une seule classe SQL que les autres appeleront quand ils en ont besoin (autrement dit à chaque méthode quasiment).

En bref je me demande si ceci est juste ou pas du tout:

SQL::$fields = 'ID, CreationDate, ModificationDate, Type';
SQL::$from = 'medias';
SQL::$where = 'Type = 1';
SQL::$orderBy = 'CreationDate DESC';
$Media = new Media();
$Media->getMedias();

Et par exemple dans la classe Media, méthode getMedias j'aurais donc à un moment donné dans le code:

$results = SQL::select();

au lieu de faire par exemple

$results = $this->getInfo();

et dans getInfo d'avoir ceci:

$sql = 'SELECT '.$this->fields.' FROM '.$this->table etc etc

Qui va donc utiliser les attributs passés ci dessus, dans ce cas là je n'ai donc plus besoin de déclarer tout ça dans la classe Media ni aucune autre puisque la classe SQL est dédiée à ce boulot, ce qui me semble plus logique.

Je sais que ça parait tordu mais le truc en lui même est tordu et sort de l'ordinaire, j'ai quasiment tout en tête mais je bute sur ce point là, enfin pas que ça ne marche pas mais ça me semble pas correcte de répéter les attributs dans chaque classe (et je ne veux pas créer non plus un ramassis de connerie car j'ai mal pensé certaines choses au départ).

Tu réinventes presque propel et doctrine

Donc le raisonnement n'est pas faux en soi, ça me rassure déjà. ^^

J'utiliserai bien doctrine mais je préfère me faire un truc sur mesure car les besoins trop spécifiques (et puis c'est pas si compliqué que ça).

Par contre je viens de remarquer que j'aurais un problème avec l'une de mes méthodes. --" (putain mais QUAND est ce que j'y arriverais !! xD)

Les besoins trop spécifiques…sans doute pas assez pour devoir te passer d'un orm comme propel ou doctine

Ah mais je dis pas que c'est merdique, bien au contraire. ^^

Seulement ici j'ai des requêtes sur 3 niveaux, mais que j'aimerais pour bien faire rassembler en une seule méthode (mais passage des 3 requêtes obligatoires si je veux un truc complet), et le soucis c'est que je ne vois pas comment je vais pouvoir avec une méthode statique les différencier (puisque avant je passais par les attributs de la classe).

A moins de passer la méthode à un objet mais là je crois que je me trompe de route... xD

En bref, j'ai une requete pour les infos, une pour les descriptions, et une pour les éventuels champs supplémentaires de la description.

En bref faut voir ça comme ça au final:

[Info]
=> ID
=> CreationDate
=> TypeID
[Descriptions]
[fre]
=> Title
=> Body
[eng]
=>Title
=>Body
[Custom]
=> Tags
=> Photo

(a chaque accolade, faut voir une indentation, pour bien faire comprendre que ça fait partie de)

Ca c'est le schéma de retour souhaité.

Donc comme tu vois ça se décompose sur 3 niveaux, et j'ai du mal à trouver la méthode qui me permet de pouvoir rechercher sur les 3 (exemple, un média dont le type est 1 ET contient le tag "news"). Or d'après mes connaissances en SGBG, faire ça en une seule requête et surtout pouvoir retourner le résultat sous cette forme est impossible (mis à part l'envoit des 3 requêtes, d'utiliser le résultat de la première dans la deuxième, et pareil pour la 3 par rapport à la 2ième).

C'est quoi la structure de ta base ?

En bref pour ce que j'ai décrit, 3 tables

Une table medias contenant la date de creation, l'auteur etc

Une table description possédant un champ TargetID faisant réference au média, là il y a des champs comme Title, Body et surtout LanguageID, et puis dans le cas où ces quelques champs ne sont pas suffisant on a en plus une table descriptions_custom qui fonctionne de la manière suivante

DescriptionID Name Value

En bref j'ai l'ID de la description, dans le champ Name c'est le nom du "champ" fictif et Value, sa valeur (pourquoi une telle structure ? Car ces champs là je les ignorent tout simplement, avec une structure comme celle là (Index => Valeur), je peux en rajouter tant que je le souhaite. Ça parait bizarre je sais mais si tu as une autre solution viable en sachant que j'ignore les champs supplémentaires, je suis preneur ^^ c'est là tout l'intérêt).

Et pour bien faire j'aimerais que la méthode me retourne la structure ci dessus. =P

Le seul moyen que j'ai trouvé est de faire ça par étape:

Trouver d'abord les infos, ensuite une fois que j'ai ça, trouvé les descriptions liées à ce média, et enfin récupérer les champs supplémentaires liés à la description.

Sachant que je peux avoir une condition sur chacune des tables évidemment.

Dans la clause IN de SQL, tu peux assez une requête. Tu peux donc faire l'ensemble des jointures nécessaires et passer en where les "IN" et "NOT IN" qu'il faudra vérifier.

Ouais mais je me retrouve avec un tableau unidimensionnel. ^^

Y'a que php pour faire ça ^^ MySQL en n'est pas capable

D'où la raison d'avoir séparer ça en plusieurs requêtes, piger maintenant le pourquoi ? =P (sinon j'aurais effectivement fait une sous-requête ^^)

Disons que tu peux un retour uni-dimensionnel de ta base de données et la formatrer des données de manière multi-dimensionnelle (d'où le traitement php).

Encore une fois, merci à Fire_Storm qui a montré que les gens sur ce forums étaient incompétents et pensés être fort, à part deepblue

Ce que je cherche à faire est franchement tordu et pour bien faire j'aimerais que ça se fasse d'une certaine manière, bref c'est pas le genre de cas qu'on rencontre habituellement donc logique que tout le monde ne réponde pas. Si je m'en foutais j'aurais fait ça n'importe comment du moment que ça me renvoit ce que je veut.

Donc avant de traiter les gens de "cons" réfléchit un peu stp la prochaine fois.

Bref faut que j'y réfléchisse encore.

J'ai jamais dit qu'ils étaient cons...mais regarde les autres topics, ils sont tout le temps la pour massacrer les noobs ou a faire genre donc voila...

Quand on traite les gens d'incompétent, laisse moi quand même douter... xD

Finalement je n'ai toujours rien trouvé de potable autre que la première solution... =/