Oué enfin c'est pas le seul a avoir ces avantages... ça n'a rien de mieux sur
ce point par rapport à du postgresql (qui me parait par contre beaucoup plus
robuste par exemple)
Attention, je ne dis pas que PostgreSQL n'est pas bien. Personnellement, pour avoir travaillé avec MySQL énormément, Oracle beaucoup, PostgreSQL pas mal aussi et SQLite un peu : pour moi le meilleur techniquement parlant c'est PostgreSQL, sans conteste. La doc est excellente, les messages d'erreurs sont très bien faits, la gestion de l'intégrité référentielle est "incluse", les types de données sont simples. MAIS c'est moins disponible que MySQL. Donc pour une application distribuée comme Piwigo, c'est un critère majeur.
Y'a aucune lib php qui permet d'abstraire les accès aux bases ?
Il y a plusieurs stratégies pour faire du code indépendant du moteur de base de données. Grosso modo :
1) on peut déléguer l'intégralité de la gestion du code SQL à une librairie et réinventer le "select url from photos where id=123" en quelque chose du genre "sqlget(arary('id'), 'photos', array('id'=>123))". L'inconvénient de cette méthode, c'est qu'elle semble sympathique sur des exemples triviaux, mais c'est ingérable sur des exemples "de la vraie vie". Au final, je trouve que ça complique le code et ça génère des requêtes SQL génériques, pas du tout optimisées.
2) ou bien fait des requêtes SQL qui marchent théoriquement partout. L'inconvénient de cette méthode, c'est que les moteurs de base de données ont beau être compatible avec les normes ANSI SQL92 par exemple, en pratique, c'est faux. Il arrive souvent qu'une même requête soit incorrecte en PostgreSQL voire pire, ne donne pas les mêmes résultats en MySQL et en PostgreSQL (testé et approuvé malheureusement).
Dans notre cas, les requêtes SQL de Piwigo sont assez travaillées côté optimisation des performances. Ce n'est pas forcément un critère important pour tous, mais pour nous c'est assez critique.
Et pourtant on est en train de commenter sur un site fait en Rails. Et le moins
qu'on puisse dire c'est que ça tourne quand même plutôt convenablement, non ?
Tout dépend de la machine que tu mets derrière. Si tu as un petit espace sur du mutualisé, il y a à mon avis plus de chance que ton appli RoR soit coupée que ton appli PHP. Sauf si tu as choisi une appli PHP codée avec les pieds, et il y a en probablement beaucoup, et le "codé avec les pieds" est très subjectif de toute façon.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par Pierrick Le Gall . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 4.
Attention, je ne dis pas que PostgreSQL n'est pas bien. Personnellement, pour avoir travaillé avec MySQL énormément, Oracle beaucoup, PostgreSQL pas mal aussi et SQLite un peu : pour moi le meilleur techniquement parlant c'est PostgreSQL, sans conteste. La doc est excellente, les messages d'erreurs sont très bien faits, la gestion de l'intégrité référentielle est "incluse", les types de données sont simples. MAIS c'est moins disponible que MySQL. Donc pour une application distribuée comme Piwigo, c'est un critère majeur.
Il y a plusieurs stratégies pour faire du code indépendant du moteur de base de données. Grosso modo :
1) on peut déléguer l'intégralité de la gestion du code SQL à une librairie et réinventer le "select url from photos where id=123" en quelque chose du genre "sqlget(arary('id'), 'photos', array('id'=>123))". L'inconvénient de cette méthode, c'est qu'elle semble sympathique sur des exemples triviaux, mais c'est ingérable sur des exemples "de la vraie vie". Au final, je trouve que ça complique le code et ça génère des requêtes SQL génériques, pas du tout optimisées.
2) ou bien fait des requêtes SQL qui marchent théoriquement partout. L'inconvénient de cette méthode, c'est que les moteurs de base de données ont beau être compatible avec les normes ANSI SQL92 par exemple, en pratique, c'est faux. Il arrive souvent qu'une même requête soit incorrecte en PostgreSQL voire pire, ne donne pas les mêmes résultats en MySQL et en PostgreSQL (testé et approuvé malheureusement).
Dans notre cas, les requêtes SQL de Piwigo sont assez travaillées côté optimisation des performances. Ce n'est pas forcément un critère important pour tous, mais pour nous c'est assez critique.
Tout dépend de la machine que tu mets derrière. Si tu as un petit espace sur du mutualisé, il y a à mon avis plus de chance que ton appli RoR soit coupée que ton appli PHP. Sauf si tu as choisi une appli PHP codée avec les pieds, et il y a en probablement beaucoup, et le "codé avec les pieds" est très subjectif de toute façon.