xml vs sql - Page 1

polop
j'ai découvert le xml récemment et je veut maintenant en mettre partout

je trouve ca bien plus souple que le sql, mais de grande questions me turlupines

1- les fichiers sont ils parsés suivants les demandes ?
exemple je fait un xpath qui va prendre /commercants/commercant[@ref="toto"]
ben en fait ce con avais déjà tout parsé et mis en objet ou alors il découvre au fur et a mesure ?
style il va tout charger jusqu'à ce qu'il rencontre 'commerçants' puis rescanner jusqu'à obtenir le/les 'commerçant' avec la ref toto ?

un peu comme va faire un éditeur de texte habile avec un .txt de 4go ?

je me pose la question car la mon xml est tout petit, mais si il fait 5 mo, et qu'à chaque page ca le recharge et rescanne ... voila quoi

si il ne parse pas à la demande, certaines lib le font peu être ? la j'utilise simplexml en php, mais il y à aussi l'objet dom etc

dans le cas contraire, la solution serais d'éclater en plein de fichiers et faire la sélection de ce qu'il faut charger moi même ?

en fait le but est de tester un peu la techno sur ce petit projet pour l'utiliser à une plus grande échelle après si c'est concluant, typiquement sur un site de vente en ligne, avec plusieurs centaines de produits

2- niveau recherche,
j'ai pas encore testé, mais il existe "contains" que je peu utiliser dans mes xpath pour sélectionner les nœud qui contiennent une sous chaine dans leurs attributs, donc similaire au like en sql, vais avoir des mauvaises surprises en l'utilisant ?

3- mise en cache
je ne peu pas stocker l'objet simple xml en session, bref je charge le xml depuis le fichier (ou la session) à chaque fois (ce qui reviens surtout à ma question 1)
* est ce plus rapide pour php de charger le fichier xml ou de le prendre depuis la session ?
* php utilise t'il un cache 'interne' pour garder le xml en ram etc ?
* un hack ou autre chose existe t'il pour sauver l'objet en session ? serialize peu etre ?
* si mon objet fait 5mo la session va elle souffrir ?

4- vous, vous faite comment ?

en fait, je ne veut pas perdre de temps la dessus si ce n'est pas assez robuste et rapide pour supporter de 'gros' xml

je répondrai qu'à 4: sauf obligation de faire ça, pour moi c'est DO NOT WANT

autant utiliser les choses adaptées. Si t'as besoin d'une base transportable, utilise sqlite, mais a mon avis tu vas te faire grave chier avec xml, surtout si t'as des insertions de données à faire, des transactions atomiques à garantir, des clés étrangères, etc.

ou alors utilise carrément un truc nosql, mais vraiment, XML pour ça, je le sentirais mal, à ta place

XML n'est pas un format prévu pour être utilisé comme une base de données. Soit ton fichier sera intégralement lu et transformé dans une représentation plus efficace, soit tes lectures seront affreusement lentes (selon la technique utilisée par la bibliothèque que tu utilises). Dans les deux cas, c'est une mauvaise idée d'utiliser du XML pour remplacer une BDD, sauf pour quelques utilisations très spécifiques.

je le sent mal justement
il y à de gros points positifs, mais si le parseur n'est pas un minimum intelligent pour éviter de TOUT scanner ca craint :/

la je n'aurais pas d'insertion de données à faire via le site, ce sera externe,
comme ca je pouvais leur vendre l'admin à la fin du contrat donc le xml simplifiais la chose ^^

niveau modif/creation des données justement, j'ai un peu testé et c'est au fur et à mesure des limitations que je déchantais un peu, mais bon rien d'insurmontable en jonglant un peu entre dom et simplexml

en fait ce qui me plais dans le xml c'est que tout est vraiment hiérarchisé, je ne sais pas vraiment faire de grosse requêtes sql tapant dans 3 tables à la fois etc, je devrais peu être apprendre mais en tout cas l'extraction de données en xml en 1000 fois plus souple je trouve :/

bon au moins j'aurais un peu testé
je continu ce projet comme ca, le prochain redeviendra plus classique

Un mot : JSON !

Kochise

[avis perso] Le XML est une abomination ayant connu un succès non mérité [/avis perso].

donc tout passer en array php ?
ca pourrais être stocké en session, mais comment effectuer des recherches dedans sans devoir tout itérer ?

c'est tout de même attrayant peu être comme toute les abomination héhé

r043v (./4) :
en fait ce qui me plais dans le xml c'est que tout est vraiment hiérarchisé, je ne sais pas vraiment faire de grosse requêtes sql tapant dans 3 tables à la fois etc, je devrais peu être apprendre mais en tout cas l'extraction de données en xml en 1000 fois plus souple je trouve :/

Et 10 000 fois plus lente...
Enfin, je ne vois même pas comment on pourrait vouloir échanger SQL et XML

parce que le graphiste à par exemple détruit la base du dernier site en dev en utilisant un outil à la con qui remplie une base depuis un .sql, c'est pas son domaine :/
bref un xml est bien plus lisible éditable et "sauvegardable" pour lui

et puis je voulais voir de nouveaux horizons

en tout cas pour ce projet le xml sera parfait, j'ai quoi, grand maximum 50 fiches par villes et un .xml par ville

la je m'intéresse un peu à redis, c'est un autre concept mais ca peu être cool, il n'y a mm pas de quoi faire des recherches de type like%

Euh si redis est bien du même genre que Cassandra, ce n'est pas *du tout* les mêmes besoins que du XML...

non

Pour info, redis, bigtable, hbase, voldemort, cassandra, etc. sont là quand mysql n'est plus assez performant, et ils strictement aucun intérêt si tu n'as qu'un ou deux serveurs de base de données

sont là quand mysql n'est plus assez performant, et ils strictement aucun intérêt

d'où tu sort ca ? c'est complètement différent de mysql

et toutes celles que tu cites sont assez différentes les unes des autres aussi,

sql est trop 'gros' à mon gout, la c'est une base légère, de type clef -> valeur, donc oui, rapide, parfaite pour des requêtes ajax par exemple, ou des structures de données simple style pour stocker des users

http://redis.io/topics/data-types-intro
http://redis.io/topics/twitter-clone
http://www.lukemelia.com/blog/archives/2010/01/17/redis-in-practice-whos-online/

forcement il manque des choses par rapport à sql mais l'inverse est aussi vrai, tu peu par exemple spécifier la durée d'une vie d'une clef, l'user s'inscrit tu met un timeout sur sa fiche de 1h et basta si il à pas validé l'email dans le temps impartis, pas de cron ou autre à mettre en place

et puis rien n'empêche de le mettre comme un 'complément' à sql et mixer les technologies, une très grosse partie de mon code exploite sql, ca va pas changer du jour au lendemain

redis a l'air sympa à utiliser.

r043v (./15) :
sql est trop 'gros' à mon gout, la c'est une base légère, de type clef -> valeur, donc oui, rapide, parfaite pour des requêtes ajax par exemple, ou des structures de données simple style pour stocker des users

A ce compte là, utilise un fichier INI ! Dans une de mes boites précédente j'avais utilisé un fichier INI comme conteneur de log, au départ ça semblait complètement fou, et au final ça a fini par donner un truc démentiel, super clean (c'était pour tracer ce que faisait cette merde d'InstallShield buggué jusqu'à la moelle, une véritable performance considérant que ce n'est qu'un "wrappeur" de MSI) Bon après j'en ai eu marre et j'ai tout passé sous InnoSetup Mais ceci est une autre histoire... Juste pour dire de ne surtout pas négliger le fichier INI !

Kochise

ca serais le même combat qu'avec xml, en cas de fichier lourd, tout est parsé, en plus je perd le xpath ^^

mais c'est pas faux, fortement comparable au xml, les nœud en moins

énorme le coup du
animal = BIRD couplé avec define('BIRD', 'Dodo bird');
http://php.net/manual/fr/function.parse-ini-file.php
php m'étonne tous les jours, il fait vraiment tout :- )

r043v (./18) :
mais c'est pas faux, fortement comparable au xml, les nœud en moins

Pas du tout, oublie pas que le nom de ta section peux contenir n'importe quoi, genre, je sais pas moi... une arborescence par exemple ? Regarde un fichier .REG, c'est qu'un fichier INI...

Kochise

c'est justement comme ca qu'il faut faire avec redis,
style la clef 'user:1124:name' c'est du bluff, ca va pas prendre l'attribut name de l'user 1124, mais ca fait une clef unique tout de même ou l'on stockera cet attribut

Zerosquare (./7) :
[avis perso] Le XML est une abomination ayant connu un succès non mérité [/avis perso].

Rappelle-moi de ne jamais te présenter à mon chef

^^

(Enfin ça serait sans doute moins pire que si tu lui disais la même chose sur le SGML, mais bon)

Et si je te disais que je pense la même chose du SGML ?
(enfin bon, c'est moins pire que le XML)

yaml for ever ?

Je suis contre les formats textuels (et l'inband-signaling, et la tolérance pour la syntaxe foireuse) pour des trucs qui sont parsés 99.99% du temps par des machines.

Ouais, mais reste les 0.01% où tu vas ouvrir ton fichier XML avec notepad pour faire une édition àlamano dans l'arborescence. C'est pas comme si une GUI pouvait te permettre de le faire. Regarde le SVG, c'est nettement mieux de composer son fichier avec un éditeur texte que d'utiliser Inkscape. A quand les fichiers images en texte ? Ah merde, PPM...

Kochise

./24 > là ça serait

0² > mais bien souvent ils sont contrôlés à un moment ou un autre par des humains, ou même générés de façon semi-automatique... Très souvent, le côté textuel du XML est très pratique.

./28 : à moins que tu l'invites à un open, je doute qu'on se rencontre un jour, donc ça va

./29 : c'est pas une raison, ç'aurait été tout aussi possible avec un format binaire et des softs faits pour ça.