Version imprimable
ben va me falloir que tu me dise ce que c'est alors,parce que pour moi une appli qui est sur un serveur et qui est utilise a distance sans autre chose qu'un navigateur cote client,c'est du client serveur.Mais les choses ont peut etre evolué :roll: :wink:Citation:
Envoyé par EJ
genre google->database xmlCitation:
Envoyé par EJ
:roll:
j'ai pas tout lu mais ca a l'air de traiter du sujet
http://www.rpbourret.com/xml/XMLDatabaseProds.htm
ps:tu serais pas une peu masochiste sur les bords :lol:
Nan pour le client-serveur, je dis pas que c'est pas client-serveur, je dis que c'est pas une appli... Enfin je veux dire que pour moi, une appli web où tu peux que regarder, pas modifier/écrire j'appelle ça un site web quoi :lol:
Maintenant ma définition n'est sans doute aps celle du W3C... :roll:
Merci pour la doc mais en fait j'ai pas trop le temps, pis l'Anglais au petit lever... :wink:
Et alors!!! Moi suis chercheur et j'ai quand meme mis 10 (== 2) secondes a comprendre la blague binaire de ta signature... Me suis fait avoir Arffff!!! :D :D :DCitation:
Envoyé par EJ
Je creuse les articles... j'edite le post des je j'ai qq chose de tangible...
Alle un petit http://forum.liveonbankiz.org/html/emoticons/sign2.gif parce que j'ai un peu creuse la question et que le sujet est interessant (c'est pour ca que je n'edite pas mon post precedent... roooh le mauvais posteur que je suis!!!)
XML est il une Base de Donnees?
Techniquement, oui. Le language sert a structurer un ensemble de donnees et dispose de nombreux outils afin d'extraire les informations utilies, autrement dit, faire une query sur le contenu...
Type de donnees: XML ou SGBDR?
Bonne question mais la tout depend du type d'information que vous souhaitez stocker. Si les donnees ont une structure tres precise et bien definie (genre carnet d'adresse), les SGBDR sont tout designes pour cette tache. Dans le cadre de donnees plus "aleatoires" tel des FAQ ou des brochures marketing, mieux vaudra preferer l'XML qui sera donc redige "a la main" par l'utilisateur...
Rapidite: XML ou SGBDR?
C'etait l'objet principal de ma recherche. Fournissant des acces multi-utilisateurs et un parcours des donnees plus rapide, les BDD acquirent un avantage certain sur l'XML. Dependant encore de l'OS et du Hardware, l'XML aurait donc une utilisation adequate au sein d'un environement disposant de peu de donnees, avec peu d'utilisateurs et demandant peu de performances... En clair, pas un site Internet!!!
Des questions supplementaires??? Je vous mets le lien d'un document en anglais trouve a partir du lien de Erwy (merci bcp de ton aide!!! :D ):
http://www.rpbourret.com/xml/XMLAndDatabases.htm
Bonne lecture... :wink:
PQ: Pour les :boulet: en anglais, ca ne vous fera pas de mal va lol !!! :lol:
les bdd c'est bien tant que tu n'as pas de jointure a faire or pour exprimer des abres ou des hierachies tu y es oblige,et la les performances souffrent d'une baisse sensibles alors que c'est la structure naturelles d'un xmlCitation:
Type de donnees: XML ou SGBDR?
Bonne question mais la tout depend du type d'information que vous souhaitez stocker. Si les donnees ont une structure tres precise et bien definie (genre carnet d'adresse), les SGBDR sont tout designes pour cette tache. Dans le cadre de donnees plus "aleatoires" tel des FAQ ou des brochures marketing, mieux vaudra preferer l'XML qui sera donc redige "a la main" par l'utilisateur...
je ne comprends pas votre fixation sur le fichier xml "a la main" ,il te sudffit de faire une interface,il n'y a de toute facon quasiment personne qui insere des donnees dans une bdd directement avec du sql donc ca revient au meme pour l'utilisateur lambda
Ce que je souhaitais dire, et je m'en excuse si c'est mal passe, c'est que l'XML sera conseille pour des donnees heterogenes dont la structure n'est pas bien definie et reguliere...
Pour la creation d'une interface, il va de soit que plus personne ne travaille avec des requetes SQL directement alors pkoi le faire avec de l'XML???
En regard des jointures, et dans le cas de donnees regulieres non complexes (ie une seule table) l'XML peut etre envisageable, tout depend de l'environement...
Desole, j'ai tente de resumer ma pensee en quelques lignes...
c'est juste que tu peux avoir des donnees reguliere bien definies et TRES complexe et donc tres difficile a utiliser directement dans une bdd(meme si tu troubve tjrs un schema pour les stocker :? )Citation:
Envoyé par danael
j'ai oublie quelque particularite du xml
1)on a oublie de dire que le xml est LE format de communication interbases
2)par rapport aux avantages/inconvenients face aux bdd,il y celui de la maintnance et des ressources,gerer des fichiers est tres simples et peu couteux,et il n'y a hjamais besoin de relancer des fichiers alors qu'une bdd peut planter(donc interface+bdd 2*plus de chance de plantage que simplement une interface + fichier)
pour moi le gros pb du xml c'est la gestion de l'ecriture.
Je precise aussi que sur le projet ou je travaille on utilise une solution mediane bdd +xml
on a en effet une grosse bdd ,dans laquelle des certaines donnees de references ne sont maj qu'une fois par 24h.Comme les structures est repartits sur au minimum 3 tables a chaque fois,que leur usage est recurrent et necessite donc des acces frequents et important,on n' a prefere les copier dans des fichiers xml sur le serveur d'appli.Ca nous permet de soulager la bdd mais surtout d'avoir des temps de reponses bien superieurs
Ca dépend. C'est sur que si on manipule des données arborescentes dans une bdd à l'aide de procédures stockées récursives (quand c'est possible d'ailleurs...), les perfs vont se faire sentir.Citation:
Envoyé par Erwy
Maintenant il existe des modèles performants et pas propriétaires (Oracle a son propre système de gestion de données hiérarchiques) pour manipuler ce type de données avec un SGBD. Je ne me suis jamais livré à des benchs comparatifs, mais je suis quasiment certain que sur des gros volumes de données, ça explose un processeur XSLT (en comparant une requête SQL à une requête XPath).
Je suis plus d'accord avec toi sur les avantages de XML quand il permet une meilleure interopérabilité, donc facilite l'intégration et l'échange de données intersystèmes (de surcroit quand ils sont hétérogènes !).
Je sais pas nous ont travaille avec 9i, mais on n'a une tres grosse base,1-2 millions d'enregistrements,et franchement le multi jointure ca reste couteuxCitation:
Envoyé par Sylvain James
Les jointures ont toujours un coût c'est clair, mais on a pas forcément besoin de jointures pour représenter des données hiérarchiques avec un SGBD.
La représentation intervallaire convient très bien, et le seul coût additionnel est induit par la gestion d'index supplémentaires (mais non obligatoires).
Sylvain
ben pas dans une structure complexe comme la notre :?
pour te donner une idee
chaque info est separe en trois tables
une table pour des codes(+quelques infos systeme)
une table pour la duree de l'application de ce code
une table pour faire la description du code(plusieurs langues plusieurs tables)
les modifs sont nombreuses sur les trois tables et on a une historisations systematique du tout
L'une des infos que j'ai mis en xml est plus complexe 4 tables en effet il y une table de rajoute pour faire la hierarchie entre les differentes description qui pointent sur le code
de plus il y a aussi une hierachie entre les codes
on a deja des index partout mais la c'est insuffisant(de + dans nos hierarchie un pere a un nombre indefini de fils)
est ce que dans ce type de structure tu vois l'avantage du xml?
D'après ce que tu décris, si si : tu peux le faire :)Citation:
ben pas dans une structure complexe comme la notre :?
Bien sur, mais sous réserve du volume de données (cf. plus haut dans l'enfilade les remarques de Danael).Citation:
est ce que dans ce type de structure tu vois l'avantage du xml?
Une autre soluce est de mixer intelligemment SGBD + sources externes XML ce que tu as l'air d'avoir fait. Si c'est bien réfléchi, ç'est souvent des solutions très performantes.
Si j'ai bien compris ton truc, la représentation intervallaire des données te donneraient de bien meilleures perf que le modèle classique Parent-enfant. Aussi, le nombre de niveau dans cette représentation est "illimité" (max(integer) quand même...)
Sylvain