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 ?
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 ?
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 ?
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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
Anonyme wrote: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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
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
qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au
Anonyme <jayce@mosx.net> wrote:
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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
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
qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au
Anonyme wrote: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) :
<http://fadace.developpez.com/sgbdcmp/>
<http://dev.mysql.com/doc/mysql/fr/Comparisons.html>
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
qu'est-ce qu'une grande base ?...
bahh une grand base ca depend, pour moi c'est une base oracle avec au
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 !
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 !
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 !
payman wrote: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
payman <payman@libertysurf.fr> wrote:
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
payman wrote: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) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...
payman wrote: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 !!! 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
cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%cfranco@pobox.com>...
payman <payman@libertysurf.fr> wrote:
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 !!! 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
(Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...
payman wrote: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 !!! 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
La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable
La légèreté à l'utilisation est un critère essentiel également, le
produit doit pouvoir tourner en mono-poste sur un ordinateur portable
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 wrote: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.
Christophe Franco <cfranco@pobox.com> wrote:
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.
Christophe Franco wrote: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.
payman wrote:(Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...payman wrote: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)
payman <payman@libertysurf.fr> wrote:
cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%cfranco@pobox.com>...
payman <payman@libertysurf.fr> wrote:
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)
payman wrote:(Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...payman wrote: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) wrote in message
news:<1gdeuoy.mfrefg1ojfxfkN%...
payman wrote:(Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...payman wrote:
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 :)
cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gdeuoy.mfrefg1ojfxfkN%cfranco@pobox.com>...
payman <payman@libertysurf.fr> wrote:
cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%cfranco@pobox.com>...
payman <payman@libertysurf.fr> wrote:
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 :)
(Christophe Franco) wrote in message
news:<1gdeuoy.mfrefg1ojfxfkN%...
payman wrote:(Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%...payman wrote:
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 :)