Discussion :

[p_mehdi]

Bonjour,

Je voudrait mettre en place une facilité de saisie de codes postaux , ville et pays dans un formulaire web de saisie de données.

Je me suis tourner vers un control toolkit ajax Autocomplete qui va me ramener "n" (J'ai choisis 10) enregistrements a chaque fois..

Je vois deux types de stockage : Xml ou base de données(sql server).

Quel serait le plus performant?

Sachant que je vais rechercher dans ces stockages avec par exemple l'entrée : "Valen"

ca va ramener : Valence,Valenciennes etc.....

Merci d'avance

[tomlev]

Ben ça dépend, il n'y en a pas un qui est intrinsèquement plus performant que l'autre... Ca dépend de la quantité de données, de si la base de données est locale ou distante, etc.

L'idéal dans un cas comme ça serait une base de données locale, pour tirer parti de l'indexation afin d'accélerer la recherche : en effet, si tu dois chercher parmi toutes les communes de France, soit environ 36000, la recherche dans un gros fichier XML risque d'être un peu longue... Par contre, si c'est une base de données distante, il faut voir si les temps de réponse et de transfert réseau ne sont pas trop importants, auquel cas le XML peut devenir plus intéressant...

Donc, en résumé, pas de réponse toute faite, il faut voir ce qui correspond le mieux à ton besoin et à ton architecture technique

[p_mehdi]

cc'est dans le cas d'un site web donc la base de donnée serait distante enfin sur le serveur.
donc si je comprends il faudrait opter pour le fichier Xml.

[Gold Bug]

cc'est dans le cas d'un site web donc la base de donnée serait distante enfin sur le serveur.
donc si je comprends il faudrait opter pour le fichier Xml.

Ben pas forcément, parce que de toutes façons le fichier XML sera sur le serveur aussi.

[Immobilis]

Salut,

Un fichier xml est interessant, si tu as plusieurs serveur IIS. Tu peux dupliquer ce moteur et ainsi répartir la charge de la recherche.
Si tu utilise les fichiers xml il faut évidement considérer la taille du fichier. Plus le fichier est gros plus ça prend de temps. Le parcours d'un fichier xml avec XPath peut être long car il navigue dans le fichier. Il peut être nécessaire de le diviser. Ainsi, l'accès à un fichier des villes commençant par "v" sera rapide.
Une base de données sera plus rapide si elle travaille sur des champs indexés.

Personnellement j'opterai tout de même pour un base SQL avec une gestion du cache dans IIS. Avec une architecture 3-tiers tu pourras facilement changer la source de données (SQL <-> Xml).

A+

[tomlev]

c'est dans le cas d'un site web donc la base de donnée serait distante

Ben pas forcément... si la base de données est hébergée sur le serveur web, du point de vue du serveur web elle est locale.

Mais de toutes façons, si elle est sur une autre machine du même réseau, la communication avec la base est pas forcément handicapante... faut faire des tests pour voir quelle est la meilleure solution

Sinon, une autre possibilité : si ce sont des données "statiques", qui changent rarement, tu peux les charger une seule fois dans une liste ou une DataTable et stocker ça dans une variable d'application, ça t'évite de les recharger à chaque fois à partir de la base ou du fichier XML.

[p_mehdi]

D'accord je comprends mieux vos explications.

Par contre le stockage dans une datatable ca veut dire que cette datatable est construite au démarrage de l'application ( dans le Global asax ? )

Ca ne pose aucun problème de stocker beaucoup de donner dans les variables d'application ?

Physiquement c'est stockée ou une variable d'application ( dans la ram du serveur ?)

[tomlev]

Par contre le stockage dans une datatable ca veut dire que cette datatable est construite au démarrage de l'application ( dans le Global asax ? )

Pas forcément au démarrage, ça peut être chargé la première fois que tu en as besoin ("lazy loading")

Ca ne pose aucun problème de stocker beaucoup de donner dans les variables d'application ?

Physiquement c'est stockée ou une variable d'application ( dans la ram du serveur ?)

Oui, c'est stocké en RAM. Donc ça peut poser problème si la quantité de données est très importante, mais à mon avis dans ton cas c'est pas si énorme (36000 communes, en supposant que chacune prend 100 octets, ça fait à peu près 3.6Mo...)

[Immobilis]

Sinon, une autre possibilité : si ce sont des données "statiques", qui changent rarement, tu peux les charger une seule fois dans une liste ou une DataTable et stocker ça dans une variable d'application, ça t'évite de les recharger à chaque fois à partir de la base ou du fichier XML.

Il faudrait tester les performances et la durée de vie, mais dans ce cas je dirais singleton. Cela permet de garder le type de la donnée. Une variable d'application doit être transtypée il me semble.

[tomlev]

Cela permet de garder le type de la donnée. Une variable d'application doit être transtypée il me semble.

Je comprends pas ce que tu veux dire... le type n'est jamais perdu. Oui, il faudra faire un transtypage, mais en quoi est-ce un problème ?

[Immobilis]

Oui, il faudra faire un transtypage, mais en quoi est-ce un problème ?

Aucun si cela ne consomme pas trop de ressources en production.
S'agissant de données en cache il faut faire une conversion à chaque accès:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.Data.DataTable dt = (System.Data.DataTable)System.Web.HttpContext.Current.Cache.Get("MaDataTableEnChache");

Sur une grande quantité de données combien de temps et quelles ressource cela prend-il?

Au contraire, les propriétés d'un singleton dont déjà typées.

A+

[tomlev]

Dans ton exemple, l'objet est déjà de type DataTable, ce n'est pas une "conversion" mais un simple cast pour dire "traite cet objet comme un DataTable". Un cast ne consomme quasiment pas de ressources...

[p_mehdi]

Merci pour toutes ces infos je vais opter pour une datatable au niveau application.