SGBDR encapsulés...

9 réponses
Avatar
Pif
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=EAme 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=E9es et
les manipuler autrement ou est ton enferm=E9 dans la technologie
propre...?

2) connaissez vous des comparatifs et sont ils tous plus int=E9ressant
que les SGBDR classique en terme de performances (pas de
fonctionnalit=E9s)

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=E9f=E9rences Java genre Derby et
Oracle Berkeley DB ou pensez vous qu'on peut s'int=E9resser =E0 des outils
"non java" mais permettant un acc=E8s et une manipulation simple depuis
java grace =E0 une API et une interface ODBC ou JDBC par exemple ?

Merci !

9 réponses

Avatar
mordicus
Pif wrote:

Bonjour, j'ai plusieurs questions sur les "Embeded RDBMS" :

1) Qu'est ce qu'un tel produit ?
- y a t-il vraiment un serveur ?



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.

- 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...).



Oui (pour derby en tout cas). Tout ce qui cause JDBC peut causer à derby
sans problèmes.

- 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



Quel serveur ? :)
Sérieusement, derby peut être serveur mais la tu pers en perfs... Forcement,
tu rajoute des couches.

- 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...?



Je crois que oui, mais j'ai pas regarder ça avec derby...

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 ?




Pour derby, disons que ce n'est pas fait pour tenir les mêmes charges qu'un
Oracle ou un Postgres. Mais franchement, je n'ai jamais eu a m'en plaindre.
Il me sert même souvent de cache local aux données qui viennent d'Oracle.

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 ?



ODBC -> pouark, et bonjour les perfs...

Tu devrais tester derby.
Avatar
Miko
J'aime bien SQLite ( http://www.sqlite.org/ ), mébon ce n'est pas tout à
fait "R" (pas d'intégrité référentielle stricte).
Pour des petites applis monoposte, c'est parfait (et léger).
Avantage: zéro config
Interfaces avec C, Java, Delphi, Tcl/Tk (mon préféré), PHP, Ruby, Python, et
j'en oublie. (http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers )


Miko
Avatar
Pif
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...
Avatar
mordicus
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...




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 ?

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 !!!]




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).

En plus, à rajouter du jni pour encapsuler le librairie (il s'agit d'une lib
ici aussi, il ne faut pas l'oublier) tu va encore perdre en perfs...

Merci pour les éclaircissements...



padkoi
Avatar
Pif
mordicus a écrit :
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 ?



ben c'est un peu la question que je me posais... je suis sur plusieurs
projets...

Et en effet, sans répliquer toute la base, ca peut servir de cache à
l'application pour le rendre plus autonome et pour le rendre plus
performante... Je pense que je vais garder mon serveur principal, et je
veux en effet réfléchir à un cache intermédiaire...

merci pour le conseil ...

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).



oracle c'est une hashtable persistante de 4 Mo en gros ?

padkoi



merci !

en y refléchissant, quand on va sur les fils java, on a souvent peu
d'info sur comment optimiser la persitance, sur les fils sgbd (mais pas
ici en l'occurence), on a peu d'info sur leinterfacage avec des langages...
c'est domage qu'il n'y ait pas des fils par exemple sur SGBD/Java par
exemple...
faut aller sur internet chercher des forums que je n'aime pas trop que
je consulte souvent via mon bon ami : google !
Avatar
Ducrot Bruno
Bonjour,

On Thu, 08 Feb 2007 23:57:23 +0100, mordicus wrote:
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.



Ne pas oublier non plus que l'on peut embarqué un serveur dans une
application.

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





Ici vous avez aussi l'option d'embarqué le serveur derby directement
dans votre application. Les autres applications seront alors
des clients qui contacteront via JDBC le serveur embarqué.
Voir
http://db.apache.org/derby/papers/DerbyTut/ns_intro.html
tout à la fin de la page.

- 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...





Et ici vous pourriez utilisez JDBC pour vos accès sur le serveur embarqué
dans l'application qui a le plus besoin de perf.

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Avatar
ownowl
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 ?



au niveau java, hsqldb fonctionne très bien. Plusieurs modes de
fonctionnements sont possibles : voir sur http://hsqldb.org/
Je l'utilise pour un cache local qui peut monter à plusieurs centaines
de Mo. bonne compatibilité SQL92. c'est la base qui est utilisée dans
openoffice

Olivier
Avatar
Jean-Marc Molina
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 :)
Avatar
Pif
Vi, embedded c'est "niché" à l'origine... embarqué j'aime pas pasque ca
connote un système mobile... les systèmes embarqués, normalement c'est
le GPS, Frigo, magnetoscope et compagnie.. en outre, quand on a un SGBD
qui est dans une librairie de type JAR, on peut utiliser encapsulé à
priori pis qu'on est bien dans un l'encapsulation dans un objet (en
java... ) ;)

Jean-Marc Molina a écrit :
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 :)