le développeur s'en moque un petit peu. Il consulte la documentation de son SGBD, celui avec lequel il travaille quotidiennement et qui lui importe le plus pour son projet et il adapte les exemples de la documentation pour son besoin de l'instant
Mon coeur de métier n'étant pas le web, j'ai plutôt une expérience différente, j'ai du travailler avec du SQLite, MySQL, postgres, firebird (heureusement, j'ai toujours pu éviter les machins propriétaires). Les ORM peuvent constituer une solution mais pas toujours, heureusement qu'il existe des couches d'abstractions comme PDO en PHP, après pour les requêtes SQL, chacun sa méthode (partir d'une implémentation générique puis on optimise pour chaque base, implémentation base par base etc ...)
Le soucis, c'est que cela signifie un chantier énorme, pour une finalité pas si énorme que ça
Pour l'utilisateur qui a déjà une instance de Postgres, c'est un gain appréciable. Après, personne ne vous oblige à maintenir un backend postgres si vous n'en avez pas l'envie/le temps/les compétences etc ..., c'est du logiciel libre, libre à chacun d'apporter sa pierre. Dans l'écosystème libriste, le consommateur "passif" n'a pas voix au chapitre, soit il met la main à la pate (pas forcément dans le code, ça peut être de la traduction, documentation, promotion, packaging etc ... un échange de bons procédés), soit il met la main au porte-monnaie.
En découplant cette partie, ça vous permettra d'être un peu plus souple à l'avenir (par exemple, supporter un autre fork de MySQL comme Drizzle ou MariaDB), faciliter les contributions externes (tout est prêt pour supporter votre base préférée, y a plus qu'à coder les requêtes SQL qui vont bien et tester -pour caricaturer), découpler les requêtes SQL du code, ça peut même faire l'objet d'un Google SoC.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par GeneralZod . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 1.
Mon coeur de métier n'étant pas le web, j'ai plutôt une expérience différente, j'ai du travailler avec du SQLite, MySQL, postgres, firebird (heureusement, j'ai toujours pu éviter les machins propriétaires). Les ORM peuvent constituer une solution mais pas toujours, heureusement qu'il existe des couches d'abstractions comme PDO en PHP, après pour les requêtes SQL, chacun sa méthode (partir d'une implémentation générique puis on optimise pour chaque base, implémentation base par base etc ...)
Pour l'utilisateur qui a déjà une instance de Postgres, c'est un gain appréciable. Après, personne ne vous oblige à maintenir un backend postgres si vous n'en avez pas l'envie/le temps/les compétences etc ..., c'est du logiciel libre, libre à chacun d'apporter sa pierre. Dans l'écosystème libriste, le consommateur "passif" n'a pas voix au chapitre, soit il met la main à la pate (pas forcément dans le code, ça peut être de la traduction, documentation, promotion, packaging etc ... un échange de bons procédés), soit il met la main au porte-monnaie.
En découplant cette partie, ça vous permettra d'être un peu plus souple à l'avenir (par exemple, supporter un autre fork de MySQL comme Drizzle ou MariaDB), faciliter les contributions externes (tout est prêt pour supporter votre base préférée, y a plus qu'à coder les requêtes SQL qui vont bien et tester -pour caricaturer), découpler les requêtes SQL du code, ça peut même faire l'objet d'un Google SoC.