[linux-neuchatel] JBOSS versus ZOPE...

Didier Frick didier at dfr.ch
Wed Jul 2 13:40:44 CEST 2003


On Wed, 2003-07-02 at 13:14, Leandro Guimarães Faria Corcete Dutra
wrote:
> Em Qua, 2003-07-02 às 12:42, Didier Frick escreveu:
> > On Tue, 2003-07-01 at 23:37, Leandro Guimarães Faria Corcete Dutra
> > wrote:
> >
> > Il n'existe _pas_ de "format relationnel" de données, seulement des
> > "bases de données" relationnelles, qui utilisent un format propriétaire
> > et chaque fois différent pour stocker les données.
> 
> 	Oui, mais la répresentation interne est irrelevant pour l'échange.
> 
Tout à fait d'accord, c'est bien le point que j'essayais de souligner.

> 	Je n'ai dit rien de format, mais de schemas.
> 
> 
> > Veux tu dire que tu préfères utiliser des fichiers SQL avec des tonnes
> > d'inserts et de "create table" pour échanger des données, plutôt que du
> > XML ? Ce n'est pas mon cas.
> 
> 	Les INSERTs ne sont pas utiles.  Il y a beaucoup de formats plus
> simples, legers et efficaces que XML, et parfaitement capables de
> reussir en l'échange de un schema relationnel.
> 
Exemple(s) ?

> 
> > Ou alors, utiliser une application 2-tiers, avec tous les composants
> > accédant directement à la base de données à travers SQL ? C'est
> > contraire à toute l'évolution récente en terme d'architecture, qui
> > préconise la séparation stricte de la logique et du stockage.
> 
> 	C'est une grande confusion causée pour SQL.  Le model relationnel
> préconise la séparation stricte de la répresentation physique, visible
> seulement pour le DBA, et la logique, qui est le schema relationnel.
> 
D'accord, n'empêche qu'il n'existe pas de standard pour représenter par
exemple un graphique, un modèle UML, un organigramme, etc... avec SQL,
contrairement à XML. Si on voulait définir des standards équivalents
sous forme relationnelle, cela obligerait tout le monde à utiliser la
même représentation interne de stockage, et ne résoudrait en rien le
problème de l'échange de données standard.

> 	SQL est suboptimal.  Le idéal serait avoir une language vraiment
> relationnel -- vide http://www.thethirdmanifesto.com/ ou
> http://dbdebunk.com./ --, mais pour le moment présent un format
> hierarchique est un retour au passé.

Moui, et combien d'applications et de frameworks supportent-ils ces
technologies _aujourd'hui_ ? D'autre part, caractériser XML comme un
"format hiérarchique" montre une focalisation sur le stockage de
données, et non sur la transmission.

Un simple regard sur
http://www.w3.org/XML/RDB.html
démontre que XML peut être utilisé pour représenter l'information sous
forme relationnelle, donc cette opposition entre XML et le relationnel
est artificielle.


> 	Il y a deux problèmes avec XML.  Un, il est inefficace, avec plus de
> labels que de données quelque fois.
> 

L'utilisation de techniques de compression permet de réduire fortement
ce problème:

http://www.idealliance.org/papers/xml02/dx_xml02/papers/06-02-04/06-02-04.html


> 	L'autre, il est hierarchique, donc difficile de changer e necessitant
> de reprogrammation pour les changements.
> 
> 

Peux tu me donner un exemple de technologie de nécéssitant pas de
reprogrammation pour les changements ? 

> 
> 	Oracle ne vend pas de bases de données, mais de systèmes de gestion de
> bases de données.  Et les systèmes de Oracle ne sont pas relationnels. 
> Is ne se conforment pas même aux standards SQL, et même SQL n'est pas
> relationnel.
> 

Ce qui veut dire dans ce cas que _personne_ aujourd'hui ne vend de
systèmes de bases de données relationnelles. Cela ne semble pas très
prometteur pour un projet devant être fini l'année prochaine...


-- 
Didier Frick  
Freelance Software Developer & Consultant
http://www.dfr.ch/





More information about the linux-neuchatel mailing list