En fait non, c'est même possible comme fonctionnement, avec un parseur SQL -> SQL. Mais bon.
Et ça existe ? Parce que, sinon, tout est possible, certes, mais on n'a pas forcément le temps ni les capacités de l'implémenter.
Par contre, que lorsque tu écris select(concat(a,b)) il te le traduise en SELECT a||b ou SELECT CONCAT(a,b) suivant la cible, ben oui c'est possible, et pire, ça existe.
Oui, donc en fait, à ce point, je n'écris plus du SQL, j'écris dans un langage qui est ensuite interprété en SQL (je pense au DQL de Doctrine, par exemple). Très peu pour moi, merci, j'aimerais éviter de multiplier les indirections.
C'est bien ça qui est décrié, c'est que tout le monde n'utilise pas de lib d'abstraction d'accès aux bases.
Oui, et ce que je dis en écrivant que je fais « comme tout le monde », c'est que ton assertion est à mon sens erronée : la plupart des projets ou des développements spécifiques un peu sérieux ont une couche d'abstraction (et la plupart du temps, c'est ADOdb ou PDO, quand ce n'est pas un ORM tel que Propel ou Doctrine). C'est même un des points que je vérifie en premier lorsque j'évalue un soft PHP.
C'est du NIH si tu réimplémente une nième vois un ORM qui existe déjà dans la nature, qui aurait déjà été testé, qui soit fiable, etc.
Mon critère de base était que ce soit basé sur ADOdb justement parce qu'elle est testée et fiable, et il y avait déjà une classe qui faisait 80 % de ce que je voulais. Pourquoi aurais-je été changer complètement de bibliothèque ? Autant tirer avantage du fait qu'on a accès aux sources, non ? Le point important reste pour moi le rapport entre temps nécessaire pour l'adaptation et avantage retiré d'un outil plus proche de ce que je souhaite.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par William Steve Applegate . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 1.
Et ça existe ? Parce que, sinon, tout est possible, certes, mais on n'a pas forcément le temps ni les capacités de l'implémenter.
Oui, donc en fait, à ce point, je n'écris plus du SQL, j'écris dans un langage qui est ensuite interprété en SQL (je pense au DQL de Doctrine, par exemple). Très peu pour moi, merci, j'aimerais éviter de multiplier les indirections.
Oui, et ce que je dis en écrivant que je fais « comme tout le monde », c'est que ton assertion est à mon sens erronée : la plupart des projets ou des développements spécifiques un peu sérieux ont une couche d'abstraction (et la plupart du temps, c'est ADOdb ou PDO, quand ce n'est pas un ORM tel que Propel ou Doctrine). C'est même un des points que je vérifie en premier lorsque j'évalue un soft PHP.
Mon critère de base était que ce soit basé sur ADOdb justement parce qu'elle est testée et fiable, et il y avait déjà une classe qui faisait 80 % de ce que je voulais. Pourquoi aurais-je été changer complètement de bibliothèque ? Autant tirer avantage du fait qu'on a accès aux sources, non ? Le point important reste pour moi le rapport entre temps nécessaire pour l'adaptation et avantage retiré d'un outil plus proche de ce que je souhaite.
Envoyé depuis mon PDP 11/70