我知道这是一个令人作呕的话题，但我也知道有些人喜欢数据库问题，所以我认为我会继续问这个问题。
我正在构建一个Web应用程序，该应用程序在最基本的级别上显示满足用户定义的搜索条件的对象列表。该应用程序的主要功能是提供一个界面，用户可以通过该界面对大量对象属性（包括数据范围，位置数据以及可能的相关数据）执行实时多面搜索。
当然也会有辅助信息：用户帐户，查询表等。
我的背景完全是在关系数据库开发中，主要是SQL Server和一点点MySQL。但是，我对对象关系方法甚至是完整文档数据库的可能适用性感到好奇。没有在这些范式中工作的经验，我不确定自己会从事什么。
以下是一些可能影响决策的考虑因素：
随着更多属性和搜索选项的添加，该模式可能会随着时间的推移发生相当大的变化，从而带来典型的版本控制/部署挑战。这是我考虑使用文档数据库的主要原因。
应用程序本身很可能使用Typescript使用Angular或React前端在Node / Express中编写，因此代码将与json格式的数据进行交互。换句话说，无论数据库服务器返回什么，我们都希望在代码级别使用json。 （文档数据库的另一种情况。）
可能存在大量搜索参数和大量数据，因此索引编制将是关键，而性能将是巨大的潜在障碍。在我看来，这对文档db来说是一个强有力的案例。
一个潜在的用例将涉及用户调整滑块控件（假设它控制高价和低价参数或距离范围）。然后将所选参数打包为json对象，并发送给搜索控制器，搜索控制器随后将这些参数在更改时传递给db服务器，并期望返回对象列表。换句话说，用户通常不会按下按钮来完善搜索条件。他们每次更改参数都会进行搜索更新。
我不知道这件事的严重程度，但是如果有某种方法可以利用可以缓存搜索结果的技术，然后在搜索范围缩小的情况下在这些结果中进行搜索，那也很好。仅在第一次搜索的较小子集上执行第二次搜索，而不是在整个可用对象范围内执行第二次搜索。
我猜想我应该问一下ORM。还有一些我通常没有经验的东西（我已经使用过一些Entity Framework），但是想知道是否应该扩大视野。
谢谢，我期待您的意见！
答案 0 :(得分：0)
我认为您的要求“存在大量的搜索参数和大量的数据，因此索引将是关键，而性能将是巨大的潜在陷阱”，这是使用关系型的有力依据数据库来存储数据。
在您的用例中，利用可以支持JSON格式数据的ORM似乎是理想的选择。生产中的系统的模式演化肯定会是一个挑战（虽然不是不可克服的），但是最好使用ORM产品，该产品至少可以轻松地在开发阶段（当事物更有可能快速变化和发展）支持模式演化。
鉴于您通常会发出的查询类型（例如，调整滑块控件），支持可包含范围条件的预准备语句的ORM会更有效。
此外，鉴于您需要“对大量对象属性进行实时的多面搜索，包括数据范围，位置数据以及可能的相关数据”，这是一种ORM产品，可以轻松支持一对一，一个搜索条件中的多对多以及多对多关系和路径表达式应简化您的开发过程。