Flex Interface de recherche: XML de charge ou une requête DB

Question

Pour une application Flex qui est utilisé pour rechercher et afficher les résultats (sans opérations d'écriture), je stocke actuellement des données dans une base de données relationnelle, mais plutôt que d'interroger la base de données via l'application , Je fais une écriture nocturne des données, y compris ses relations, à un fichier XML. Puis, à l'aide de Flex, je charge ce fichier XML, l'analyse en objets personnalisés et "interroge" ces objets si nécessaire.

Cela fonctionne très bien - en filtrant fondamentalement une ArrayCollection de ces objets en fonction des critères de recherche.

Par rapport à l'interrogation de la base de données, la recherche en texte intégral, par exemple, est extrêmement rapide dans ce scénario.

Mais quels sont les inconvénients potentiels? Quelle est la validité de cette approche? Toutes les pensées seraient grandement appréciées.

Merci d'avance.

Answer 1

La réponse courte est: ... Désolé, il n'y a pas de réponse courte. La réponse longue est la suivante: les décisions d'architecture impliquent toujours une sorte de compromis. Quelle est la bonne décision pour votre application, dépend principalement de votre contenu et de la conception globale de votre système. La seule chose que je peux dire à coup sûr est: Ce que vous faites maintenant empêche une séparation nette des préoccupations. Par exemple: Si vous avez effectué la recherche sur le serveur, vous pouvez éventuellement modifier les noms de champs, etc. dans la base de données sans que votre client le sache, car vous pouvez ajuster la sortie de données réelle pour correspondre au "vieux" modèle , même si la requête était complètement différente. Le client prendrait soin d'afficher les données, le serveur prendrait soin de les conserver et de les récupérer. C'est ce que vous voudriez probablement, si vous développez dans une équipe plus grande, ou si votre application est longue, a des transactions complexes et/ou change le comportement souvent, par exemple dans un scénario d'entreprise. Ces scénarios prennent généralement en compte une plus grande contrainte sur le serveur et donc un besoin de matériel plus puissant, car le coût du matériel n'est pas le souci le plus pressant pour les grandes entreprises. En fonction de la taille de votre ensemble de données complet, la charge du réseau serait considérablement réduite, car vous n'auriez pas besoin de tout transférer au client, mais seulement des résultats pertinents. Donc, si la connexion réseau de votre serveur est limitée, ou si vos utilisateurs ont tendance à avoir des connexions plus lentes, ce serait probablement une bonne idée. D'un autre côté: Si vous effectuez une recherche dans votre application cliente et que vous l'interrogez, vous supprimez la base de données et le serveur Web, ce qui n'est pas toujours une mauvaise chose, surtout si la capacité de votre serveur est limité, et la performance est cruciale. Mais en plus d'augmenter le trafic réseau global, cela signifie également que vous comptez beaucoup plus sur l'ordinateur client: a) Il doit être assez rapide pour gérer la recherche, et b) vous devez toujours (re) déployer une application mise à jour à l'utilisateur, chaque fois que votre modèle de données change même légèrement. Il s'agit probablement d'une source majeure d'erreurs, vous devrez donc implémenter une sorte de vérification de version pour empêcher un client obsolète de se connecter au serveur et/ou désactiver la mise en cache du navigateur. Donc, à la fin, vous devez peser le pour et le contre, puis décider quelle solution convient le mieux à vos besoins. Et vous pourriez envisager d'utiliser un moteur de recherche dédié comme Lucene comme troisième option.