Bonsoir à vous,
étant un newbie en SGBD, je me pose quelques questions :
La plus part des projet web de gestion de contenus fonctionnent avec
MySQL, quelques uns avec PostgreSQL, pour ma part je me suis mis à MySQL
depuis peu et jusqu'ici tout va bien, ce qui me chiffonne par contre
c'est que certains groupware demandent PostgreSQL.
C'est pas que je suis de mauvaise foi mais j'ai pas vraiment le temps de
me mettre à ce SGBDR, n-y a t'il pas un moyen de "contourner cette
contrainte? et pour quelle raison MySQL et PostgrSQL ne sont il pas
"compatible" entre eux?
J'adhère totalement aux concepts du Libre, mais cette pseudo pagaille
qui nous oblige à choisir une solution ou une autre (même Open Source!)
me dérange un peu, donc soyez indulgent avec et merci de m'éclairer...
@+
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour créer un projet web (CMS, groupware, Forum...) qui soit aussi bien compatible MySQL, PostgreSQL ou Firebird. @+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR. Le "problème" c'est que quand on choisit un SGBDR particulier, on est vite tenté d'utiliser ses particularités, et adieu la "portabilité" de SQL... Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que les procédures stockées. Dans ce cas cela reporte le problème de mise au point de la compatibilité des requêtes dans les proc stock ce qui est plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double maintenance pour 2 SGBDR différents ? Le langage des proc stockées est très différent d'un SGBDR à un autre...
Cordialement
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro
<brouardf@club-internet.fr> a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour
créer un projet web (CMS, groupware, Forum...) qui soit aussi bien
compatible MySQL, PostgreSQL ou Firebird.
@+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR.
Le "problème" c'est que quand on choisit un SGBDR particulier, on est
vite tenté d'utiliser ses particularités, et adieu la "portabilité" de
SQL...
Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que les
procédures stockées. Dans ce cas cela reporte le problème de mise au
point de la compatibilité des requêtes dans les proc stock ce qui est
plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double
maintenance pour 2 SGBDR différents ? Le langage des proc stockées est
très différent d'un SGBDR à un autre...
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour créer un projet web (CMS, groupware, Forum...) qui soit aussi bien compatible MySQL, PostgreSQL ou Firebird. @+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR. Le "problème" c'est que quand on choisit un SGBDR particulier, on est vite tenté d'utiliser ses particularités, et adieu la "portabilité" de SQL... Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que les procédures stockées. Dans ce cas cela reporte le problème de mise au point de la compatibilité des requêtes dans les proc stock ce qui est plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double maintenance pour 2 SGBDR différents ? Le langage des proc stockées est très différent d'un SGBDR à un autre...
Cordialement
Fred Brouard - SQLpro
Gilles TOURREAU a écrit :
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour créer un projet web (CMS, groupware, Forum...) qui soit aussi bien compatible MySQL, PostgreSQL ou Firebird. @+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR. Le "problème" c'est que quand on choisit un SGBDR particulier, on est vite tenté d'utiliser ses particularités, et adieu la "portabilité" de SQL... Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que les procédures stockées. Dans ce cas cela reporte le problème de mise au point de la compatibilité des requêtes dans les proc stock ce qui est plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double maintenance pour 2 SGBDR différents ? Le langage des proc stockées est très différent d'un SGBDR à un autre...
Bien évidemment, mais c'est beaucoup plus simple et plus souple que d'installer des version de clients lourd et autres exe...
A +
Cordialement
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Gilles TOURREAU a écrit :
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro
<brouardf@club-internet.fr> a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour
créer un projet web (CMS, groupware, Forum...) qui soit aussi bien
compatible MySQL, PostgreSQL ou Firebird.
@+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR.
Le "problème" c'est que quand on choisit un SGBDR particulier, on est
vite tenté d'utiliser ses particularités, et adieu la "portabilité"
de SQL...
Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que
les procédures stockées. Dans ce cas cela reporte le problème de mise
au point de la compatibilité des requêtes dans les proc stock ce qui
est plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double
maintenance pour 2 SGBDR différents ? Le langage des proc stockées est
très différent d'un SGBDR à un autre...
Bien évidemment, mais c'est beaucoup plus simple et plus souple que
d'installer des version de clients lourd et autres exe...
A +
Cordialement
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Le Fri, 15 Jun 2007 09:50:40 +0200, Fred Brouard - SQLpro a écrit:
Miko a écrit :
Bethebeast a écrit :
Merci pour les précisions mais je me demande si ya pas un moyen pour créer un projet web (CMS, groupware, Forum...) qui soit aussi bien compatible MySQL, PostgreSQL ou Firebird. @+
Il suffit d'employer le tronc commun SQL à ces trois SGBDR. Le "problème" c'est que quand on choisit un SGBDR particulier, on est vite tenté d'utiliser ses particularités, et adieu la "portabilité" de SQL... Miko
le plus simple est d'éviter les requêtes ad hoc et de n'utiliser que les procédures stockées. Dans ce cas cela reporte le problème de mise au point de la compatibilité des requêtes dans les proc stock ce qui est plus souple puisque le code client sera inchangé.
A +
Mais utiliser les procédures stockées ne nécessite pas une double maintenance pour 2 SGBDR différents ? Le langage des proc stockées est très différent d'un SGBDR à un autre...
Bien évidemment, mais c'est beaucoup plus simple et plus souple que d'installer des version de clients lourd et autres exe...
A +
Cordialement
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
