2010-12-30 2 views
0

Для приложения Flex, которое используется для поиска и отображения результатов (без операций записи), я в настоящее время храню данные в реляционной базе данных , но вместо того, чтобы запрашивать DB через приложение , Я делаю ночную запись данных, включая его отношения, в файл XML.Интерфейс Flex Search: загрузка XML или запроса DB

Затем через Flex я загружаю этот XML-файл, разбору его в пользовательские объекты и «запрашивая» эти объекты по мере необходимости.

Он работает очень хорошо - в основном фильтрация ArrayCollection этих объектов на основе критериев поиска.

В отличие от запросов к БД, полнотекстовый поиск, например, чрезвычайно быстрый в этом сценарии.

Но каковы некоторые потенциальные недостатки? Насколько важен такой подход? Любые мысли были бы весьма признательны.

Заранее спасибо.

ответ

1

Короткий ответ: ... Извините, нет короткого ответа.

Долгий ответ таков: Архитектурные решения всегда связаны с каким-то компромиссом. Какое правильное решение для вашего приложения, в основном зависит от вашего контента и общего дизайна вашей системы.

Единственное, что я могу сказать наверняка: то, что вы сейчас делаете, предотвращает чистое разделение проблем.

Например: если вы выполнили поиск на сервере, вы можете изменить имена полей и т. Д. В базе данных, если ваш клиент никогда не знает об этом, поскольку вы можете настроить фактический вывод данных в соответствии с «старой» моделью , даже если запрос был совершенно другим. Клиент будет следить за отображением данных, сервер будет заботиться о сохранении и извлечении данных. Это то, что вы, вероятно, захотите, если вы работаете в более крупной команде или если ваше приложение работает долгое время, часто возникают сложные транзакции и/или изменения поведения, например, в корпоративном сценарии. Эти сценарии обычно учитывают большую нагрузку на сервер и, следовательно, потребность в более мощном оборудовании, поскольку стоимость оборудования не является самой насущной проблемой для крупных компаний.

В зависимости от того, насколько велик ваш полный набор данных, это также значительно снизит нагрузку на сеть, поскольку вам не нужно будет передавать все это клиенту, а только соответствующие результаты. Таким образом, если сетевое подключение вашего сервера ограничено или ваши пользователи имеют более медленные соединения, это, вероятно, будет хорошей идеей.

С другой стороны: при поиске и запросе внутри вашего клиентского приложения, как вы его описываете, вы берете нагрузку на базу данных и веб-сервер, что не всегда плохо, особенно если емкость вашего сервера ограниченность и производительность имеют решающее значение.

Но помимо увеличения общего сетевого трафика это также означает, что вы полагаетесь на клиентский компьютер намного больше: a) он должен быть достаточно быстрым для обработки поиска, и b) вы всегда должны (повторно) развертывать обновленное приложение для пользователя, каждый раз, когда ваша модель данных изменяется незначительно. Это, возможно, главный источник ошибок, поэтому вам нужно будет выполнить некоторую проверку версий, чтобы предотвратить устаревание клиента с сервером и/или отключить кеширование браузера.

Итак, в конце концов, вы должны взвесить все за и против, а затем решить, какое решение лучше всего подходит вашим потребностям. И вы можете рассмотреть возможность использования выделенной поисковой системы, например, Lucene в качестве третьего варианта.