Bonjour, pour faire une base de donnée avec Java, sous linux, que me
conseillez vous entre les deux sur des question de performance, respect
des normes de SQL, documentation et stabilité des versions, robustesse,
facilité d'administration, au niveau des drivers JDBC éventuellement ?
ton applie doit faire quoi, il est vrai que hsqldb peut convenir, mais cela va dépendre des spécs de l'applie que tu dois réaliser ?
Question hsqldb, l'admin est vraiment très facile. Par exemple, une base "essai" a un essai.script comme ça :
<code sql> CREATE TABLE T_COUNTRY_CTY(CTY_ID INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,CTY_DESC VARCHAR(24),CTY_FLAG_URL VARCHAR(64),CTY_NICK VARCHAR(4),CTY_DEFAULT_LANG_NICK VARCHAR(4),CONSTRAINT SYS_CT_7 UNIQUE(CTY_ID,CTY_DESC,CTY_FLAG_URL,CTY_NICK)) CREATE USER SA PASSWORD "" ADMIN CREATE USER YVON PASSWORD "YVON5533" ADMIN INSERT INTO T_COUNTRY_CTY VALUES(1,'France','FR.gif','FR','fr') INSERT INTO T_COUNTRY_CTY VALUES(2,'Australie','AU.gif','AU','en') [...] </code sql>
donc on peut éditer à la "mimine" la base, qqfois plus facile qu'une classe java ... -- Yvon Thoraval
Trognon Patrice
Yvon Thoraval wrote:
Trognon Patrice wrote:
ton applie doit faire quoi, il est vrai que hsqldb peut convenir, mais cela va dépendre des spécs de l'applie que tu dois réaliser ?
Question hsqldb, l'admin est vraiment très facile. Par exemple, une base "essai" a un essai.script comme ça :
<code sql> CREATE TABLE T_COUNTRY_CTY(CTY_ID INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,CTY_DESC VARCHAR(24),CTY_FLAG_URL VARCHAR(64),CTY_NICK VARCHAR(4),CTY_DEFAULT_LANG_NICK VARCHAR(4),CONSTRAINT SYS_CT_7 UNIQUE(CTY_ID,CTY_DESC,CTY_FLAG_URL,CTY_NICK)) CREATE USER SA PASSWORD "" ADMIN CREATE USER YVON PASSWORD "YVON5533" ADMIN INSERT INTO T_COUNTRY_CTY VALUES(1,'France','FR.gif','FR','fr') INSERT INTO T_COUNTRY_CTY VALUES(2,'Australie','AU.gif','AU','en') [...] </code sql>
donc on peut éditer à la "mimine" la base, qqfois plus facile qu'une classe java ...
Certe, enfin bon l'admin d'un MySQL est aussi très facile. Ce qui n'est pas le cas d'un postgres qui lui est un peu plus coton.
Maintenant je suis quand même reservé sur le fait d'avoir une base SQL en Java, donc AMHA si le but est d'avoir une base en java je partirais plutot sur du db4object.
Bon, faut voir ce qu'il veut faire faire a son applie, ca on ne le sait pas, sa question manque d'infos pour qu'il puisse avoir une réponse vraiment pertinente.
ton applie doit faire quoi, il est vrai que hsqldb peut
convenir, mais cela va dépendre des spécs de l'applie
que tu dois réaliser ?
Question hsqldb, l'admin est vraiment très facile. Par exemple, une base
"essai" a un essai.script comme ça :
<code sql>
CREATE TABLE T_COUNTRY_CTY(CTY_ID INTEGER GENERATED BY DEFAULT AS
IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,CTY_DESC
VARCHAR(24),CTY_FLAG_URL VARCHAR(64),CTY_NICK
VARCHAR(4),CTY_DEFAULT_LANG_NICK VARCHAR(4),CONSTRAINT SYS_CT_7
UNIQUE(CTY_ID,CTY_DESC,CTY_FLAG_URL,CTY_NICK))
CREATE USER SA PASSWORD "" ADMIN
CREATE USER YVON PASSWORD "YVON5533" ADMIN
INSERT INTO T_COUNTRY_CTY VALUES(1,'France','FR.gif','FR','fr')
INSERT INTO T_COUNTRY_CTY VALUES(2,'Australie','AU.gif','AU','en')
[...]
</code sql>
donc on peut éditer à la "mimine" la base, qqfois plus facile qu'une
classe java ...
Certe, enfin bon l'admin d'un MySQL est aussi très facile.
Ce qui n'est pas le cas d'un postgres qui lui est un peu plus coton.
Maintenant je suis quand même reservé sur le fait d'avoir une
base SQL en Java, donc AMHA si le but est d'avoir une base en
java je partirais plutot sur du db4object.
Bon, faut voir ce qu'il veut faire faire a son applie, ca on
ne le sait pas, sa question manque d'infos pour qu'il puisse
avoir une réponse vraiment pertinente.
ton applie doit faire quoi, il est vrai que hsqldb peut convenir, mais cela va dépendre des spécs de l'applie que tu dois réaliser ?
Question hsqldb, l'admin est vraiment très facile. Par exemple, une base "essai" a un essai.script comme ça :
<code sql> CREATE TABLE T_COUNTRY_CTY(CTY_ID INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 0) NOT NULL PRIMARY KEY,CTY_DESC VARCHAR(24),CTY_FLAG_URL VARCHAR(64),CTY_NICK VARCHAR(4),CTY_DEFAULT_LANG_NICK VARCHAR(4),CONSTRAINT SYS_CT_7 UNIQUE(CTY_ID,CTY_DESC,CTY_FLAG_URL,CTY_NICK)) CREATE USER SA PASSWORD "" ADMIN CREATE USER YVON PASSWORD "YVON5533" ADMIN INSERT INTO T_COUNTRY_CTY VALUES(1,'France','FR.gif','FR','fr') INSERT INTO T_COUNTRY_CTY VALUES(2,'Australie','AU.gif','AU','en') [...] </code sql>
donc on peut éditer à la "mimine" la base, qqfois plus facile qu'une classe java ...
Certe, enfin bon l'admin d'un MySQL est aussi très facile. Ce qui n'est pas le cas d'un postgres qui lui est un peu plus coton.
Maintenant je suis quand même reservé sur le fait d'avoir une base SQL en Java, donc AMHA si le but est d'avoir une base en java je partirais plutot sur du db4object.
Bon, faut voir ce qu'il veut faire faire a son applie, ca on ne le sait pas, sa question manque d'infos pour qu'il puisse avoir une réponse vraiment pertinente.
-- Cordialement,
Patrice Trognon http://wwW.javadevel.com
yvon.thoravalNO
Trognon Patrice wrote:
Bon, faut voir ce qu'il veut faire faire a son applie, ca on ne le sait pas, sa question manque d'infos pour qu'il puisse avoir une réponse vraiment pertinente.
Bon, faut voir ce qu'il veut faire faire a son applie, ca on
ne le sait pas, sa question manque d'infos pour qu'il puisse
avoir une réponse vraiment pertinente.
Bon, faut voir ce qu'il veut faire faire a son applie, ca on ne le sait pas, sa question manque d'infos pour qu'il puisse avoir une réponse vraiment pertinente.
toutafé :) -- Yvon Thoraval
mordicus
Trognon Patrice wrote:
Yvon Thoraval wrote:
Certe, enfin bon l'admin d'un MySQL est aussi très facile. Ce qui n'est pas le cas d'un postgres qui lui est un peu plus coton.
Ah bon ? et en quoi c'est un peu plus coton ? et surtout qu'est-ce que des scripts de création de tables ont avoir avec l'admin d'un serveur ?
Puis bon, un psql -f fichier.sql c'est vrai que ca décoiffe point de vue complexité...
Trognon Patrice wrote:
Yvon Thoraval wrote:
Certe, enfin bon l'admin d'un MySQL est aussi très facile.
Ce qui n'est pas le cas d'un postgres qui lui est un peu plus coton.
Ah bon ? et en quoi c'est un peu plus coton ? et surtout qu'est-ce que
des scripts de création de tables ont avoir avec l'admin d'un serveur ?
Puis bon, un psql -f fichier.sql c'est vrai que ca décoiffe point de vue
complexité...
Ah bon ? et en quoi c'est un peu plus coton ? et surtout qu'est-ce que des scripts de création de tables ont avoir avec l'admin d'un serveur ?
le backup, la mise au point et c.
backup_up à chaud sans soucis par pg_dump !!! pour la mise au point, explicite car je ne vois strictement aucune différence.
Pif
j'ai peut de tables, mais de très grosses tables, assez simples d'autre part au niveau de la structure.
En fait, on m'a transmis des a priori comme quoi MySQL n'est pas un SGBD digne de ce nom, assez lent, ... Un expérience m'a montré que le MySQL SQL est assez instable récemment, de fonctions ont encore changées, et plein de choses pas pratiques...
Alors j'aimerais savoir si tout cela est devenu faut et si il reste stable sur le principal, et en quoi Postgre serait réellement bien mieux...
J'ai pas de très lourdes exigences, je souhaite simplement rester le plus standard possible, si MySQL le permet, c'est parfait...
Par contre, pour mes test, mon serveur tourne sous une mandrake 10.1 et un PIII 500 avec 128 de RAM... (heureusement, c'est tout ce qu'il héberge :) ) mes tables font quelques gigas... outre la taille de la BD, l'un ou les deux risquent ils de s'avérer lourd ou non ?
Je souhaite rester sur du JDBC avec un SQL standard, portable linux/windows... à partir de la à votre bon coeur pour les conseils... :)
merci d'avance !
j'ai peut de tables, mais de très grosses tables, assez simples d'autre
part au niveau de la structure.
En fait, on m'a transmis des a priori comme quoi MySQL n'est pas un SGBD
digne de ce nom, assez lent, ...
Un expérience m'a montré que le MySQL SQL est assez instable récemment,
de fonctions ont encore changées, et plein de choses pas pratiques...
Alors j'aimerais savoir si tout cela est devenu faut et si il reste
stable sur le principal, et en quoi Postgre serait réellement bien mieux...
J'ai pas de très lourdes exigences, je souhaite simplement rester le
plus standard possible, si MySQL le permet, c'est parfait...
Par contre, pour mes test, mon serveur tourne sous une mandrake 10.1 et
un PIII 500 avec 128 de RAM... (heureusement, c'est tout ce qu'il
héberge :) )
mes tables font quelques gigas... outre la taille de la BD, l'un ou les
deux risquent ils de s'avérer lourd ou non ?
Je souhaite rester sur du JDBC avec un SQL standard, portable
linux/windows... à partir de la à votre bon coeur pour les conseils... :)
j'ai peut de tables, mais de très grosses tables, assez simples d'autre part au niveau de la structure.
En fait, on m'a transmis des a priori comme quoi MySQL n'est pas un SGBD digne de ce nom, assez lent, ... Un expérience m'a montré que le MySQL SQL est assez instable récemment, de fonctions ont encore changées, et plein de choses pas pratiques...
Alors j'aimerais savoir si tout cela est devenu faut et si il reste stable sur le principal, et en quoi Postgre serait réellement bien mieux...
J'ai pas de très lourdes exigences, je souhaite simplement rester le plus standard possible, si MySQL le permet, c'est parfait...
Par contre, pour mes test, mon serveur tourne sous une mandrake 10.1 et un PIII 500 avec 128 de RAM... (heureusement, c'est tout ce qu'il héberge :) ) mes tables font quelques gigas... outre la taille de la BD, l'un ou les deux risquent ils de s'avérer lourd ou non ?
Je souhaite rester sur du JDBC avec un SQL standard, portable linux/windows... à partir de la à votre bon coeur pour les conseils... :)
merci d'avance !
Pif
heu, je souhaite faire des programmes en java via JDBC, peu m'importe le langage d'implémentation du SGBD... du coup, (et pourtant je suis fan de java), c'est pas trop lent en Java HSQLDB en comparaison d'un PG ou MySQL ?
merci !
heu, je souhaite faire des programmes en java via JDBC, peu m'importe le
langage d'implémentation du SGBD... du coup, (et pourtant je suis fan de
java), c'est pas trop lent en Java HSQLDB en comparaison d'un PG ou MySQL ?
heu, je souhaite faire des programmes en java via JDBC, peu m'importe le langage d'implémentation du SGBD... du coup, (et pourtant je suis fan de java), c'est pas trop lent en Java HSQLDB en comparaison d'un PG ou MySQL ?
