Рассмотрение параметров базы данных для нового веб-приложения - PullRequest
0 голосов
/ 26 января 2019

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

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

Конечно, будет дополнительная информация: учетные записи пользователей, таблицы поиска и т. Д.

Мой опыт полностью связан с разработкой реляционных баз данных, в первую очередь SQL Server с небольшим количеством MySQL. Тем не менее, я заинтригован возможной применимостью объектно-реляционного подхода или даже полной базы данных документов. Без опыта работы в этих парадигмах я не уверен, во что я мог бы ввязаться.

Вот некоторые дополнительные соображения, которые могут повлиять на решение:

  • Схема, вероятно, со временем значительно изменится, поскольку будет добавлено больше свойств и параметров поиска, что создаст типичные проблемы управления версиями / развертывания. Это основная причина, по которой я бы рассмотрел базу данных документов.

  • Само приложение, скорее всего, будет написано в Node / Express с интерфейсом Angular или React с использованием Typescript, поэтому код будет взаимодействовать с данными в формате json. Другими словами, независимо от того, что возвращается с сервера db, нам нужен json на уровне кода. (Другой случай для базы данных документов.)

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

В возможном случае использования пользователь может настроить ползунок (скажем, он контролирует параметры высокой и низкой цены или диапазон расстояний). Затем выбранные параметры будут упакованы как объект json и отправлены в контроллер поиска, который затем передаст эти параметры на сервер БД при изменении и получит список возвращаемых объектов. Другими словами, пользователь обычно не будет нажимать кнопку для уточнения критериев поиска. Обновление поиска будет происходить при каждом изменении параметра.

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

Полагаю, пока я на этом, мне следует спросить об ОРМ. Кроме того, кое-что, с чем я обычно не сталкивался (я немного использовал Entity Framework), но мне интересно, стоит ли мне расширять свой кругозор.

Спасибо, и я с нетерпением жду вашего мнения!

1 Ответ

0 голосов
/ 28 января 2019

Я думаю, что ваше требование «Существует потенциал для большого количества параметров поиска и большого количества данных, поэтому индексирование будет ключевым, а производительность будет огромным потенциальным уловом», дает веские основания для использования реляционного база данных для хранения данных.

Использование ORM, который может поддерживать данные в формате JSON, в вашем случае показалось бы идеальным. Эволюция схемы для производственной системы, безусловно, будет проблемой (хотя и не является непреодолимой), но было бы неплохо использовать продукт ORM, который, по крайней мере, может легко поддерживать эволюцию схемы на этапе разработки, когда вероятность того, что ситуация изменится и быстро эволюционирует.

Учитывая тип запросов, которые вы обычно выполняете (например, настройку ползункового элемента управления), ORM, который поддерживает подготовленные операторы, которые могут иметь критерии диапазона, будет более эффективным.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...