database - 考虑新 Web 应用程序的数据库选项

我知道这是一个令人作呕的话题，但我也知道有些人喜欢对数据库发表意见，所以我想我还是继续问这个问题。

我正在构建一个 Web 应用程序，它在非常基本的级别上显示满足用户定义的搜索条件的对象列表。该应用程序的主要功能是提供一个界面，用户可以通过该界面对大量对象属性执行实时分面搜索，包括数据范围、位置数据和可能的相关数据。

当然也会有辅助信息：用户帐户、查找表等。

我的背景完全是关系数据库开发，主要是 SQL Server 和一点点 MySQL。但是，我对对象关系方法甚至完整文档数据库的可能适用性很感兴趣。如果没有在这些范式中工作的经验，我不确定自己可能会陷入什么困境。

以下是一些可能影响决定的进一步考虑因素：

随着更多属性和搜索选项的添加，模式可能会随着时间的推移而发生相当大的变化，从而产生典型的版本控制/部署挑战。这是我考虑使用文档数据库的主要原因。
应用程序本身可能会使用 Typescript 使用带有 Angular 或 React 前端的 Node/Express 编写，因此代码将与 json 格式的数据进行交互。换句话说，无论从 db 服务器返回什么，我们都希望在代码级别上使用 json。（文档数据库的另一种情况。）
存在大量搜索参数和大量数据的潜力，因此索引将是关键，性能将是一个巨大的潜在问题。在我看来，这似乎是一个针对文档数据库的有力案例。

一个潜在的用例将涉及用户调整滑块控件（假设它控制高低价格参数或距离范围）。然后将选定的参数打包为 json 对象并发送到搜索控制器，然后搜索控制器将这些参数在更改时传递给 db 服务器，并期望返回一个对象列表。换言之，用户通常不会按下按钮来细化搜索标准。每次更改参数时都会发生搜索更新。

我不知道这在多大程度上是一回事，但如果有某种方法可以利用可以缓存搜索结果的技术，然后在搜索范围缩小时在这些结果中搜索，从而执行第二次，那就太好了仅搜索第一次搜索的较小子集，而不是可用对象的整个宇宙。

我想当我在做的时候，我应该问一下 ORM。还有一些我通常没有经验的东西（我使用过一些实体框架）但想知道我是否应该扩大我的视野。

谢谢，我期待您的意见！

标签： databaseormrelational-databasedocument-database

我认为您对“可能存在大量搜索参数和大量数据，因此索引将是关键，性能将是一个巨大的潜在问题”的要求为使用关系数据库进行存储提供了强有力的理由数据。

在您的用例中，利用可以支持 JSON 格式数据的 ORM 似乎是理想的选择。生产中系统的模式演化肯定是一个挑战（尽管并非无法克服），但最好使用一个 ORM 产品，该产品至少可以在开发阶段轻松支持模式演化，此时事情更有可能快速变化和发展。

考虑到您通常会发出的查询类型（例如，调整滑块控件），支持可以具有范围标准的准备好的语句的 ORM 会更有效。

此外，鉴于您需要“对大量对象属性执行实时分面搜索，包括数据范围、位置数据和可能相关的数据”，一个可以轻松支持一对一、一对一的 ORM 产品搜索条件中的许多和多对多关系和路径表达式应该可以简化您的开发过程。