Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
1) Qu'est ce qu'un tel produit ?
- y a t-il vraiment un serveur ?
- est il tout de même possible d'utiliser un SQL standard et des
ateliers de Genie Log genre SQLDevelopper, DBDesigner4, et compagnie
(gratuit ou open-source...).
- est il possible d'interroger le serveur autrement que par le code de
l'appli, et d'avoir une supervision (exemple MySQL GUI Tools,
PHPxxAdmin
- est il possible de demander des dump ou d'exporter les données et
les manipuler autrement ou est ton enfermé dans la technologie
propre...?
2) connaissez vous des comparatifs et sont ils tous plus intéressant
que les SGBDR classique en terme de performances (pas de
fonctionnalités)
3) quelles les limites qu'imposent ce genre d'outil exactement ?
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
1) Qu'est ce qu'un tel produit ?
- y a t-il vraiment un serveur ?
- est il tout de même possible d'utiliser un SQL standard et des
ateliers de Genie Log genre SQLDevelopper, DBDesigner4, et compagnie
(gratuit ou open-source...).
- est il possible d'interroger le serveur autrement que par le code de
l'appli, et d'avoir une supervision (exemple MySQL GUI Tools,
PHPxxAdmin
- est il possible de demander des dump ou d'exporter les données et
les manipuler autrement ou est ton enfermé dans la technologie
propre...?
2) connaissez vous des comparatifs et sont ils tous plus intéressant
que les SGBDR classique en terme de performances (pas de
fonctionnalités)
3) quelles les limites qu'imposent ce genre d'outil exactement ?
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
1) Qu'est ce qu'un tel produit ?
- y a t-il vraiment un serveur ?
- est il tout de même possible d'utiliser un SQL standard et des
ateliers de Genie Log genre SQLDevelopper, DBDesigner4, et compagnie
(gratuit ou open-source...).
- est il possible d'interroger le serveur autrement que par le code de
l'appli, et d'avoir une supervision (exemple MySQL GUI Tools,
PHPxxAdmin
- est il possible de demander des dump ou d'exporter les données et
les manipuler autrement ou est ton enfermé dans la technologie
propre...?
2) connaissez vous des comparatifs et sont ils tous plus intéressant
que les SGBDR classique en terme de performances (pas de
fonctionnalités)
3) quelles les limites qu'imposent ce genre d'outil exactement ?
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
Tu devrais tester derby.
Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
Tu devrais tester derby.
Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
Tu devrais tester derby.
On 8 fév, 21:15, mordicus wrote:Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
Tu devrais tester derby.
Que vaut oracle ? A faire du oracle éventuellement, vaut il mieux
faire du bdb java ou du bdb "tout court" pour encapsuler dans un
programme java... car les deux sembles dispo... mais sans vouloir
critiquer mon propre choix ... un serveur en C est souvent plus
rapide ;) [CECI N'EST PAS UN TROLL !!!]
Merci pour les éclaircissements...
On 8 fév, 21:15, mordicus <mordi...@free.fr> wrote:
Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
Tu devrais tester derby.
Que vaut oracle ? A faire du oracle éventuellement, vaut il mieux
faire du bdb java ou du bdb "tout court" pour encapsuler dans un
programme java... car les deux sembles dispo... mais sans vouloir
critiquer mon propre choix ... un serveur en C est souvent plus
rapide ;) [CECI N'EST PAS UN TROLL !!!]
Merci pour les éclaircissements...
On 8 fév, 21:15, mordicus wrote:Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
Tu devrais tester derby.
Que vaut oracle ? A faire du oracle éventuellement, vaut il mieux
faire du bdb java ou du bdb "tout court" pour encapsuler dans un
programme java... car les deux sembles dispo... mais sans vouloir
critiquer mon propre choix ... un serveur en C est souvent plus
rapide ;) [CECI N'EST PAS UN TROLL !!!]
Merci pour les éclaircissements...
Pif wrote:
Les performances de derby viennent du fait que c'est une librairie, tu
n'aura sans doute pas les mêmes performances avec le serveur derby.
Pourquoi ne pas mettre les données dans un Oracle (un vrai) ou dans un
Postgres et répliquer dans un derby (ou autre) pour pouvoir fouiller
tranquillement ?
Non, ce n'est pas un troll, nous sommes d'accord mais dans ce cas la, tu
renonce à jdbc et tout les outils standards qui vont avec (que ce soit la
version C ou Java).
padkoi
Pif wrote:
Les performances de derby viennent du fait que c'est une librairie, tu
n'aura sans doute pas les mêmes performances avec le serveur derby.
Pourquoi ne pas mettre les données dans un Oracle (un vrai) ou dans un
Postgres et répliquer dans un derby (ou autre) pour pouvoir fouiller
tranquillement ?
Non, ce n'est pas un troll, nous sommes d'accord mais dans ce cas la, tu
renonce à jdbc et tout les outils standards qui vont avec (que ce soit la
version C ou Java).
padkoi
Pif wrote:
Les performances de derby viennent du fait que c'est une librairie, tu
n'aura sans doute pas les mêmes performances avec le serveur derby.
Pourquoi ne pas mettre les données dans un Oracle (un vrai) ou dans un
Postgres et répliquer dans un derby (ou autre) pour pouvoir fouiller
tranquillement ?
Non, ce n'est pas un troll, nous sommes d'accord mais dans ce cas la, tu
renonce à jdbc et tout les outils standards qui vont avec (que ce soit la
version C ou Java).
padkoi
Pif wrote:On 8 fév, 21:15, mordicus wrote:Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui, une seule JVM a la fois... d'ou le serveur derby qui lui te permet
d'avoir plusieurs JVM qui attaquent la base.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
Pif wrote:
On 8 fév, 21:15, mordicus <mordi...@free.fr> wrote:
Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui, une seule JVM a la fois... d'ou le serveur derby qui lui te permet
d'avoir plusieurs JVM qui attaquent la base.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
Pif wrote:On 8 fév, 21:15, mordicus wrote:Non, c'est même le but, souvent c'est juste une librairie. Dans le cas de
derby, c'est juste un .jar que tu livre avec ton appli.
donc tu ne peux pas partager la base de données ? Tout les services
qu'on souhaite fournir doivent être gérés par l'appli qui encapsule le
BDE... Il faut le voir comme un librairie de manipulation de fichier
par exemple...?
Oui, une seule JVM a la fois... d'ou le serveur derby qui lui te permet
d'avoir plusieurs JVM qui attaquent la base.
Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.
mais imaginons : je développe un serveur qui encapsule un servlet...
je veux à un instant donner superviser le contenu de la base.. est il
possible d'avoir un accès partagé entre l'appli qui gère le service et
une autre (calculs statistiques et reporting, un client de SQL qui
s'interface en JDBC, ...) ou faut il système plus serveur...
En fait, je suis sur deux projet :
- fouille de données avec des performance, mais pas d'accès partagé,
mais le besoin de consulter, superviser les données.... j'ai besoin de
perfs, pas d'accès partagé, mais j'ai pas de problème pour
l'installation et l'administration d'un serveur
- un système de formulaires et d'enquetes sur le web, et pour le
déployer, un système encapsulé serait intéressant pour simplifier
l'installation et le maintenance... le service est entierement assuré
par un servlet.. Mais je veux parfois lancer des outils de reporting,
d'ajout d'utilisateurs, etc. de temps en temps... sans interrombre le
serveur, et avec des applis distinctes du serveur.. la j'ai besoin de
fournir un outil simple à installer et à maintenir, mais j'ai pas
besoin de performances, les systèmes les plus lourds doivent pouvoir
répondre au besoin sans souci...
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
4) si je suis en Java, me conseillez vous des produits particulier ?
Vaut il mieux s'orienter vers des références Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'intéresser à des outils
"non java" mais permettant un accès et une manipulation simple depuis
java grace à une API et une interface ODBC ou JDBC par exemple ?
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Pif wrote:Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Tu veux sans doute parler des "Embedded DBMS". En français on parle de bases
locales ou embarquées à l'application. L'encapsulation c'est en POO et la
décapsulation c'est pour les soirées arrosées :)
Pif wrote:
Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Tu veux sans doute parler des "Embedded DBMS". En français on parle de bases
locales ou embarquées à l'application. L'encapsulation c'est en POO et la
décapsulation c'est pour les soirées arrosées :)
Pif wrote:Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :
Tu veux sans doute parler des "Embedded DBMS". En français on parle de bases
locales ou embarquées à l'application. L'encapsulation c'est en POO et la
décapsulation c'est pour les soirées arrosées :)