Интерфейс поиска Flex: загрузка XML или Query DB - PullRequest
0 голосов
/ 30 декабря 2010

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

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

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

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

Какие потенциальные недостатки?Насколько обоснован этот подход?Любые мысли будут с благодарностью.

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

1 Ответ

1 голос
/ 02 января 2011

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

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

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

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

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

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

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

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

...