Comparatif SGBD (in Cahiers du Programmeur Mac OS X)

Le
cfranco
Bonjour à tous,

J'ai sous les yeux un exemplaire du livre "Cahiers du Programmeur Mac OS
X" - excellente lecture, n'est-ce pas ? ;-) - et j'y lis (p.220) qu'on
peut trouver un comparatif des fonctionnalités des principaux SGBD
libres et commerciaux du marché sur le site de MySQL, à l'adresse :

http://www.mysql.com/crash-me-choose.html


Problème : l'adresse en question ne mène plus à rien, et j'ai eu beau
fouiller autant que possible le site de MySQL, je n'ai rien retrouvé de
tel.

Est-ce que quelqu'un aurait éventuellement archivé cette page à l'époque
où elle était là, ou bien aurait d'autres liens sur le même sujet ?

--
Christophe Franco
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Anonyme
Le #416890
Christophe Franco
J'ai sous les yeux un exemplaire du livre "Cahiers du Programmeur Mac OS
X" - excellente lecture, n'est-ce pas ? ;-) -


(tout à fait... :-) )

et j'y lis (p.220) qu'on
peut trouver un comparatif des fonctionnalités des principaux SGBD
libres et commerciaux du marché sur le site de MySQL, à l'adresse :

http://www.mysql.com/crash-me-choose.html


Problème : l'adresse en question ne mène plus à rien, et j'ai eu beau
fouiller autant que possible le site de MySQL, je n'ai rien retrouvé de
tel.

Est-ce que quelqu'un aurait éventuellement archivé cette page à l'époque
où elle était là, ou bien aurait d'autres liens sur le même sujet ?


j'ai pas retouvé la page en question, mais en cherchant sur google, j'en
ai trouvé deux autres (le deuxième est plus dans l'esprit du lien cité
il me semble) :




--
Anonyme ( )
********* MosX.net
cfranco
Le #416887
Anonyme
et j'y lis (p.220) qu'on
peut trouver un comparatif des fonctionnalités des principaux SGBD
libres et commerciaux du marché sur le site de MySQL, à l'adresse :

http://www.mysql.com/crash-me-choose.html


Problème : l'adresse en question ne mène plus à rien, et j'ai eu beau
fouiller autant que possible le site de MySQL, je n'ai rien retrouvé de
tel.

Est-ce que quelqu'un aurait éventuellement archivé cette page à l'époque
où elle était là, ou bien aurait d'autres liens sur le même sujet ?


j'ai pas retouvé la page en question, mais en cherchant sur google, j'en
ai trouvé deux autres (le deuxième est plus dans l'esprit du lien cité
il me semble) :




Merci beaucoup. La première adresse correspond en effet à des
comparatifs que je qualifierais de "qualitatifs", comme on en trouve
beaucoup (trop ?), mais qui n'avancent souvent pas beaucoup d'arguments
concrêts (pourquoi PostgreSQL est tantôt conseillé pour une base
moyenne, tantôt pour une grande base, qu'est-ce qu'une grande base ?...)

A partir du second lien, j'ai retrouvé semble-t-il mon bonheur :
http://dev.mysql.com/tech-resources/crash-me.php

--
Christophe Franco


payman
Le #419400
(Christophe Franco) wrote in message news:
Anonyme
et j'y lis (p.220) qu'on
peut trouver un comparatif des fonctionnalités des principaux SGBD
libres et commerciaux du marché sur le site de MySQL, à l'adresse :

http://www.mysql.com/crash-me-choose.html


Problème : l'adresse en question ne mène plus à rien, et j'ai eu beau
fouiller autant que possible le site de MySQL, je n'ai rien retrouvé de
tel.

Est-ce que quelqu'un aurait éventuellement archivé cette page à l'époque
où elle était là, ou bien aurait d'autres liens sur le même sujet ?


j'ai pas retouvé la page en question, mais en cherchant sur google, j'en
ai trouvé deux autres (le deuxième est plus dans l'esprit du lien cité
il me semble) :




Merci beaucoup. La première adresse correspond en effet à des
comparatifs que je qualifierais de "qualitatifs", comme on en trouve
beaucoup (trop ?), mais qui n'avancent souvent pas beaucoup d'arguments
concrêts (pourquoi PostgreSQL est tantôt conseillé pour une base
moyenne, tantôt pour une grande base, qu'est-ce qu'une grande base ?...)

A partir du second lien, j'ai retrouvé semble-t-il mon bonheur :
http://dev.mysql.com/tech-resources/crash-me.php


hello,

Postgresql est conseillé pour des bases de tailles moyennes
pourquoi ? parce que y a Oracle pour les grandes bases voir tres
grandes,puis postgreql ca pose des problemes pour deplacement
des données etc (y tjs pas de tablespace etc ...) enfin, problemes de
maintenances/Replication/reindexations etc...

mais bon a ta place je ferais des comparatifs moi meme
car
1- je ne sais pas de quand ca date le comparatif (j'ai le deja
vu il y a plus d'un ans) et je peux te dire que postgresql a evolué
mais vraiement pas mal et j'ai hate de voir la 7.5
(Transactions impriqué etc.)

2- L'utilisation ? tu veux faire quoi, en quel langage etc ...
exemple : moi je fais du C++ donc postgresql + plpgsql + libpqxx etc
...

mais bon !!! il existe des tres grosses base mysql / php et ca roule
aussi !

qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au

moins
une 100 de tables et plusieurs millions de lignes par table + les
indexes
triggers , packages , etc ...

J'espere que ca t'aidera un peu !

A+
Payman



cfranco
Le #419399
payman
Postgresql est conseillé pour des bases de tailles moyennes
pourquoi ? parce que y a Oracle pour les grandes bases voir tres
grandes,puis postgreql ca pose des problemes pour deplacement
des données etc (y tjs pas de tablespace etc ...) enfin, problemes de
maintenances/Replication/reindexations etc...


C'est intéressant ce que tu dis là, parce que j'organise les
développements avec eXtreme Programming, et l'aspect refactoring est
essentiel. Dans un projet précédent, où les bases utilisées étaient
Access et Oracle, c'est ce qui a tout fait foirer à plusieurs reprises :
trop difficile de faire des modifications de structure proprement.

mais bon a ta place je ferais des comparatifs moi meme
car
1- je ne sais pas de quand ca date le comparatif (j'ai le deja
vu il y a plus d'un ans) et je peux te dire que postgresql a evolué
mais vraiement pas mal et j'ai hate de voir la 7.5
(Transactions impriqué etc.)

2- L'utilisation ? tu veux faire quoi, en quel langage etc ...
exemple : moi je fais du C++ donc postgresql + plpgsql + libpqxx etc
...


Java pour le langage. En premier choix, pour de tout petits besoins,
j'envisage d'ailleurs HSQLDB, mais je suis forcé d'envisager qu'il
puisse être un jour trop limité pour des grosses bases (pas forcément
limité par rapport à la taille de la base, il n'est limité que par
l'espace disque et la taille des fichiers (un par table), mais ça rame
terriblement quand une ou plusieurs tables devient trop pleine)

Comprendre : quand je dis "petite base" ou "grosse base", pour mon
projet, c'est pas en fonction de la structure des tables, mais du
contenu. Toutes les bases de tous les clients auront la même structure,
mais selon les cas ça sera plus ou moins plein...

mais bon !!! il existe des tres grosses base mysql / php et ca roule
aussi !

qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au

moins
une 100 de tables et plusieurs millions de lignes par table + les
indexes
triggers , packages , etc ...

J'espere que ca t'aidera un peu !


Oui, là je suis un peu interloqué, jusque là on avait une base de plus
de 200 tables avec tout ça, gérée sur Access et Oracle (le choix
d'Oracle uniquement décidé quand le contenu devient trop gros pour
Access, sinon ça tournait bien avec Access). Mais on a le sentiment
qu'Oracle est surdimensionné pour ça, sachant qu'on va avoir nettement
moins de tables dans la base de notre nouveau projet (probablement moins
de 100), mais pas forcément moins de données dans la base que dans
l'ancien projet, possiblement plus même.

Un critère aussi, important pour nous, la taille de la base vide (juste
sa structure). Avec Oracle, avec notre base de notre ancien projet, de
200 et quelques tables, on arrivait à une base vide de 11Go, autrement
dit extrèmement galère à manipuler (pas possible de mettre ça sur un
DVD, et je ne parle même pas des clients qui exigent une livraison sur
_un_ CD d'installation). Avec la même structure sur Access, ça passait à
quelques centaines de Mo, nettement mieux. Avec HSQLDB, quelques
dizaines de Mo probablement (pas testé encore).

La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable

--
Christophe Franco


payman
Le #419398
(Christophe Franco) wrote in message news:
payman
Postgresql est conseillé pour des bases de tailles moyennes
pourquoi ? parce que y a Oracle pour les grandes bases voir tres
grandes,puis postgreql ca pose des problemes pour deplacement
des données etc (y tjs pas de tablespace etc ...) enfin, problemes de
maintenances/Replication/reindexations etc...


C'est intéressant ce que tu dis là, parce que j'organise les
développements avec eXtreme Programming, et l'aspect refactoring est
essentiel. Dans un projet précédent, où les bases utilisées étaient
Access et Oracle, c'est ce qui a tout fait foirer à plusieurs reprises :
trop difficile de faire des modifications de structure proprement.


Effectivement modifier schema avec oracle est galere avec 8i fallait
creer une autre table et migrer les donnees mais sur 9i un peut plus simple
mais bon (j'ai pas eu le temps de voir 10g encore)!!
C'est aussi le cas sur Postgresql !


mais bon a ta place je ferais des comparatifs moi meme
car
1- je ne sais pas de quand ca date le comparatif (j'ai le deja
vu il y a plus d'un ans) et je peux te dire que postgresql a evolué
mais vraiement pas mal et j'ai hate de voir la 7.5
(Transactions impriqué etc.)

2- L'utilisation ? tu veux faire quoi, en quel langage etc ...
exemple : moi je fais du C++ donc postgresql + plpgsql + libpqxx etc
...


Java pour le langage. En premier choix, pour de tout petits besoins,
j'envisage d'ailleurs HSQLDB, mais je suis forcé d'envisager qu'il
puisse être un jour trop limité pour des grosses bases (pas forcément
limité par rapport à la taille de la base, il n'est limité que par
l'espace disque et la taille des fichiers (un par table), mais ça rame
terriblement quand une ou plusieurs tables devient trop pleine)

Comprendre : quand je dis "petite base" ou "grosse base", pour mon
projet, c'est pas en fonction de la structure des tables, mais du
contenu. Toutes les bases de tous les clients auront la même structure,
mais selon les cas ça sera plus ou moins plein...


Oui oui ce que j'avais compris pour la taille! sur projet oracle
on a 150 tables (schema de base) et chaque tables contient plusieurs
millions de ligne ! (faut dire que y a 5 DBA qui s'occupe de tous ca :)) )


je pense que avec postgresql ca devrait marcher sans probleme
y a les drivers JDBC que j'ai recuperer l'autre jour pour faire
un essai en javascript !


mais bon !!! il existe des tres grosses base mysql / php et ca roule
aussi !

qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au

moins
une 100 de tables et plusieurs millions de lignes par table + les
indexes
triggers , packages , etc ...

J'espere que ca t'aidera un peu !


Oui, là je suis un peu interloqué, jusque là on avait une base de plus
de 200 tables avec tout ça, gérée sur Access et Oracle (le choix
d'Oracle uniquement décidé quand le contenu devient trop gros pour
Access, sinon ça tournait bien avec Access). Mais on a le sentiment
qu'Oracle est surdimensionné pour ça, sachant qu'on va avoir nettement
moins de tables dans la base de notre nouveau projet (probablement moins
de 100), mais pas forcément moins de données dans la base que dans
l'ancien projet, possiblement plus même.

Un critère aussi, important pour nous, la taille de la base vide (juste
sa structure). Avec Oracle, avec notre base de notre ancien projet, de
200 et quelques tables, on arrivait à une base vide de 11Go, autrement
dit extrèmement galère à manipuler (pas possible de mettre ça sur un
DVD, et je ne parle même pas des clients qui exigent une livraison sur
_un_ CD d'installation). Avec la même structure sur Access, ça passait à
quelques centaines de Mo, nettement mieux. Avec HSQLDB, quelques
dizaines de Mo probablement (pas testé encore).

La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable


oulaaa Oracle livré sur un CD effectivement c'est pas jouable
par contre schema de la base oui, mais faut se deplacer chez
l'utilisateur finalepour faire l'install (sqlplus), c'est comme ca
que j'ai installé la base du boulot a la maison cad export de schema
en sql puis un coup de sqlplus! mais bon faut avoir deja le serveur
Oracle installé chez le client.

La base vide pese 13Mo a peu pres sur Postgresql mais de toute facon
tu a un installeur qui fait ca!
au niveau de creation schema et donnees de depart de ton projet suffit
de faire un dump ou dumpall qui genere un fichier texte (SQL) que tu peux
ensuite injecte dans la base vide au moment d'install!

ensuite un outils tres pratique pgAdmin III un peu genre sqlnav ou Toad
simple mais agreable a utiliser (mieux que en shell et a la mano)
mais ca n'existe pas sur Mac donc Windows ou linux !

Ahh oui!!! Portablilité de l'appli !!!!
Postgresql n'existe pas sous Windows (enfin pas encore et pas en natif)
faut installer cygwin d'apres mes infos c'est en cours de dev. et ca
devrait sortir avec meme licence que MacOS X et Linux donc gratos

qq adresses utiles:
http://www.entropy.ch/software/macosx/postgresql/ (installeur pour OS X etc...)
http://developer.apple.com/internet/opensource/postgres.html
http://pgadmin.postgresql.org
http://jdbc.postgresql.org/
puis pas mal de newsgroup et mailing list chez postgresql.org

A+
Payman



cfranco
Le #419397
payman
(Christophe Franco) wrote in message
news:

payman
Postgresql est conseillé pour des bases de tailles moyennes
pourquoi ? parce que y a Oracle pour les grandes bases voir tres
grandes,puis postgreql ca pose des problemes pour deplacement
des données etc (y tjs pas de tablespace etc ...) enfin, problemes de
maintenances/Replication/reindexations etc...


C'est intéressant ce que tu dis là, parce que j'organise les
développements avec eXtreme Programming, et l'aspect refactoring est
essentiel. Dans un projet précédent, où les bases utilisées étaient
Access et Oracle, c'est ce qui a tout fait foirer à plusieurs reprises :
trop difficile de faire des modifications de structure proprement.


Effectivement modifier schema avec oracle est galere avec 8i fallait
creer une autre table et migrer les donnees mais sur 9i un peut plus simple
mais bon (j'ai pas eu le temps de voir 10g encore)!!
C'est aussi le cas sur Postgresql !


Et connais-tu des SGBD pour lesquels cela peut être plus simple ? Je
suis ouvert à tout, pouvu que ça soit utilisable avec Java (via JDBC, ce
qui laisse la porte ouverte à pas mal de choses), et de préférence avec
une licence libre qui ne soit pas GPL.

mais bon !!! il existe des tres grosses base mysql / php et ca roule
aussi !

qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au

moins
une 100 de tables et plusieurs millions de lignes par table + les
indexes
triggers , packages , etc ...

J'espere que ca t'aidera un peu !


Oui, là je suis un peu interloqué, jusque là on avait une base de plus
de 200 tables avec tout ça, gérée sur Access et Oracle (le choix
d'Oracle uniquement décidé quand le contenu devient trop gros pour
Access, sinon ça tournait bien avec Access). Mais on a le sentiment
qu'Oracle est surdimensionné pour ça, sachant qu'on va avoir nettement
moins de tables dans la base de notre nouveau projet (probablement moins
de 100), mais pas forcément moins de données dans la base que dans
l'ancien projet, possiblement plus même.

Un critère aussi, important pour nous, la taille de la base vide (juste
sa structure). Avec Oracle, avec notre base de notre ancien projet, de
200 et quelques tables, on arrivait à une base vide de 11Go, autrement
dit extrèmement galère à manipuler (pas possible de mettre ça sur un
DVD, et je ne parle même pas des clients qui exigent une livraison sur
_un_ CD d'installation). Avec la même structure sur Access, ça passait à
quelques centaines de Mo, nettement mieux. Avec HSQLDB, quelques
dizaines de Mo probablement (pas testé encore).

La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable


oulaaa Oracle livré sur un CD effectivement c'est pas jouable
par contre schema de la base oui, mais faut se deplacer chez
l'utilisateur finalepour faire l'install (sqlplus), c'est comme ca
que j'ai installé la base du boulot a la maison cad export de schema
en sql puis un coup de sqlplus! mais bon faut avoir deja le serveur
Oracle installé chez le client.

La base vide pese 13Mo a peu pres sur Postgresql mais de toute facon
tu a un installeur qui fait ca!
au niveau de creation schema et donnees de depart de ton projet suffit
de faire un dump ou dumpall qui genere un fichier texte (SQL) que tu peux
ensuite injecte dans la base vide au moment d'install!

ensuite un outils tres pratique pgAdmin III un peu genre sqlnav ou Toad
simple mais agreable a utiliser (mieux que en shell et a la mano)
mais ca n'existe pas sur Mac donc Windows ou linux !

Ahh oui!!! Portablilité de l'appli !!!!
Postgresql n'existe pas sous Windows (enfin pas encore et pas en natif)
faut installer cygwin d'apres mes infos c'est en cours de dev. et ca
devrait sortir avec meme licence que MacOS X et Linux donc gratos


Oui, ça c'est aussi un point effectivement, sachant que ça va tourner
essentiellement sous Windows, en tout cas pour les install mono-postes.

Une install via Cygwin pourrait être une solution, pourvu que le client
l'accepte (because certains clients ont des accords d'exclusivité au
niveau Unix avec tel ou tel éditeur)

--
Christophe Franco




pmanet
Le #419395
Christophe Franco
La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable


si ça tourne sur Access, il est certainement possible de le porter avec
profit sur 4D, voire meme sur Filemaker pro (dans sa version 7)

ces bases supportent notamment des modifs on line de leur structure.
les temps de developpement sont infiniment plus court que les bouzins
genre oracle et machin sql de tout type.
l'administration locale est à la portée de n'importe quel crétin, ce qui
est un avantage majeur.
l'exploitation des données ne nécessite pas 3 ans de formation, ce qui
est un autre avantage fondamental.

penser à des solutions xxxSQL pour des bases monoposte me semble...
étrange.

--
Philippe Manet


cfranco
Le #419394
manet
Christophe Franco
La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable


si ça tourne sur Access, il est certainement possible de le porter avec
profit sur 4D, voire meme sur Filemaker pro (dans sa version 7)


C'est plus qu'exclu, je ne connaîs que trop ces produits...

ces bases supportent notamment des modifs on line de leur structure.
les temps de developpement sont infiniment plus court que les bouzins
genre oracle et machin sql de tout type.
l'administration locale est à la portée de n'importe quel crétin, ce qui
est un avantage majeur.
l'exploitation des données ne nécessite pas 3 ans de formation, ce qui
est un autre avantage fondamental.


...honnêtement, ces idées-là sont à mon sens des idées recues bien loin
de la réalité... Le "quick-and-dirty", ça eut marché, mais ça ne marche
plus, à très court terme je veux bien que ça prenne un petit peu moins
de temps (et encore, on est de toutes manières toujours plus rapide dans
un langage qu'on connaît), mais ne serait-ce qu'à moyen terme.... ouille
ouille ouille l'évolutivité et la maintenance. Ca devient très vite
ingérable.

J'ai bossé suffisamment longtemps à refaire dans des langages sérieux
des cochonneries bâclées sous 4D pour le savoir...

penser à des solutions xxxSQL pour des bases monoposte me semble...
étrange.


Quand je dit qu'il doit pouvoir tourner en mono-poste, c'est bien
entendu en sous-entendu que dans 90% des cas, il va tourner en
client-serveur avec n clients simultanés (n pouvant être de l'ordre de
la dizaine, au minimum), et dans les 10% de cas restants sur un portable
en monoposte, mais avec synchro sur le serveur central quand
l'utilisateur rentre de vadrouille. Et quand bien même, un HDSLQB par
exemple reste infiniment plus léger qu'un Access, Filemaker ou 4D. Même
un MySQL ou un PostgreSQL.

Autre argument de poids : c'est pas open-source...

--
Christophe Franco


payman
Le #419280
(Christophe Franco) wrote in message news:
payman
(Christophe Franco) wrote in message
news:

payman
Postgresql est conseillé pour des bases de tailles moyennes
pourquoi ? parce que y a Oracle pour les grandes bases voir tres
grandes,puis postgreql ca pose des problemes pour deplacement
des données etc (y tjs pas de tablespace etc ...) enfin, problemes de
maintenances/Replication/reindexations etc...


C'est intéressant ce que tu dis là, parce que j'organise les
développements avec eXtreme Programming, et l'aspect refactoring est
essentiel. Dans un projet précédent, où les bases utilisées étaient
Access et Oracle, c'est ce qui a tout fait foirer à plusieurs reprises :
trop difficile de faire des modifications de structure proprement.


Effectivement modifier schema avec oracle est galere avec 8i fallait
creer une autre table et migrer les donnees mais sur 9i un peut plus simple
mais bon (j'ai pas eu le temps de voir 10g encore)!!
C'est aussi le cas sur Postgresql !


Et connais-tu des SGBD pour lesquels cela peut être plus simple ? Je
suis ouvert à tout, pouvu que ça soit utilisable avec Java (via JDBC, ce
qui laisse la porte ouverte à pas mal de choses), et de préférence avec
une licence libre qui ne soit pas GPL.


Plus simple, non !!!
Deja si tu trouve un SGBD en open source (GPL) portable Mac/PC/unix
en dehors de Postgresql/Mysql c'est miracle :)

j'avais utilisé CodeBase (www.sequiter) a une epoque mais pas de serveur
sur Mac uniquement client le produit est payant mais tu a le code et sans
royaltee mais bon tjs galere pour modifier le schema, je dirais
pire que postgresql (Codebase : Langage DBase ou Foxpro quand on fait du
C ou C++)

ensuite des SGBD que j'ai jamais essayé:
Sybase j'ai lu qq part qu'il y a un client MacOS
y a aussi le projet FireBird mais bon ??? (http://firebird.sourceforge.net/)

puis les commer. :
FrontBase / dtf etc ... que je te propose pas du tout c'est assez chero
puis royaltee qui va avec

a mon avis un SGBD MacOS X/Windows en GPL avec les divers JDBC pas trop
galere a trouver (surtout sous X) = Postgresql/Mysql
cote serveur c'est simple soit un MacOS X soit un linux
cote client JDBC

Pour Oracle c'est plus chaud, Le serveur sur MacOS X est assez penible a
installer faut un OS X Server avec 512Mo de mem minimum etc ...
et sur Windows les premiers 9i planté sans arrete la machine j'en ai eu
marre un RedHat8 et Oracle 9i et depuis jamais reboote :)

voila les infos que j'ai
regarde cote http://www.developpez.com/
souvent y a pas mal d'infos mais c'est du Windows

A+
Payman


mais bon !!! il existe des tres grosses base mysql / php et ca roule
aussi !

qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au

moins
une 100 de tables et plusieurs millions de lignes par table + les
indexes
triggers , packages , etc ...

J'espere que ca t'aidera un peu !


Oui, là je suis un peu interloqué, jusque là on avait une base de plus
de 200 tables avec tout ça, gérée sur Access et Oracle (le choix
d'Oracle uniquement décidé quand le contenu devient trop gros pour
Access, sinon ça tournait bien avec Access). Mais on a le sentiment
qu'Oracle est surdimensionné pour ça, sachant qu'on va avoir nettement
moins de tables dans la base de notre nouveau projet (probablement moins
de 100), mais pas forcément moins de données dans la base que dans
l'ancien projet, possiblement plus même.

Un critère aussi, important pour nous, la taille de la base vide (juste
sa structure). Avec Oracle, avec notre base de notre ancien projet, de
200 et quelques tables, on arrivait à une base vide de 11Go, autrement
dit extrèmement galère à manipuler (pas possible de mettre ça sur un
DVD, et je ne parle même pas des clients qui exigent une livraison sur
_un_ CD d'installation). Avec la même structure sur Access, ça passait à
quelques centaines de Mo, nettement mieux. Avec HSQLDB, quelques
dizaines de Mo probablement (pas testé encore).

La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable


oulaaa Oracle livré sur un CD effectivement c'est pas jouable
par contre schema de la base oui, mais faut se deplacer chez
l'utilisateur finalepour faire l'install (sqlplus), c'est comme ca
que j'ai installé la base du boulot a la maison cad export de schema
en sql puis un coup de sqlplus! mais bon faut avoir deja le serveur
Oracle installé chez le client.

La base vide pese 13Mo a peu pres sur Postgresql mais de toute facon
tu a un installeur qui fait ca!
au niveau de creation schema et donnees de depart de ton projet suffit
de faire un dump ou dumpall qui genere un fichier texte (SQL) que tu peux
ensuite injecte dans la base vide au moment d'install!

ensuite un outils tres pratique pgAdmin III un peu genre sqlnav ou Toad
simple mais agreable a utiliser (mieux que en shell et a la mano)
mais ca n'existe pas sur Mac donc Windows ou linux !

Ahh oui!!! Portablilité de l'appli !!!!
Postgresql n'existe pas sous Windows (enfin pas encore et pas en natif)
faut installer cygwin d'apres mes infos c'est en cours de dev. et ca
devrait sortir avec meme licence que MacOS X et Linux donc gratos


Oui, ça c'est aussi un point effectivement, sachant que ça va tourner
essentiellement sous Windows, en tout cas pour les install mono-postes.

Une install via Cygwin pourrait être une solution, pourvu que le client
l'accepte (because certains clients ont des accords d'exclusivité au
niveau Unix avec tel ou tel éditeur)






cfranco
Le #419279
payman
(Christophe Franco) wrote in message
news:

payman
(Christophe Franco) wrote in message
news:

payman

Effectivement modifier schema avec oracle est galere avec 8i fallait
creer une autre table et migrer les donnees mais sur 9i un peut plus
simple mais bon (j'ai pas eu le temps de voir 10g encore)!! C'est
aussi le cas sur Postgresql !


Et connais-tu des SGBD pour lesquels cela peut être plus simple ? Je
suis ouvert à tout, pouvu que ça soit utilisable avec Java (via JDBC, ce
qui laisse la porte ouverte à pas mal de choses), et de préférence avec
une licence libre qui ne soit pas GPL.


Plus simple, non !!!
Deja si tu trouve un SGBD en open source (GPL) portable Mac/PC/unix
en dehors de Postgresql/Mysql c'est miracle :)


Mauvais exemple déjà, parce que PostgreSQL c'est du BSD, et MySQL c'est
du GPL seulement quand ça veut bien...

Mais plus ça va, et plus je pense que je vais me tourner vers
PostgreSQL, c'était mon idée de départ, mais j'avoue que j'étais un peu
freiné par l'absence de version native Windows. Là j'ai vu qu'en fait il
a l'air compilable sous Windows, des gens l'ont fait, ça devrait aller.
En plus, j'ai mis la main sur des infos sur PostGIS, qui devrait être
d'un grand intérêt pour mon projet...

merci à tous !

--
Christophe Franco




Publicité
Poster une réponse
Anonyme