Database 考虑新web应用程序的数据库选项

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

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

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

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

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

• 随着更多属性和搜索选项的添加，该模式可能会随着时间的推移而发生很大的变化，从而产生典型的版本控制/部署挑战。这是我考虑文档数据库的主要原因。

• 应用程序本身很可能是在Node/Express中使用Typescript编写的，具有Angular或React前端，因此代码将与json格式的数据交互。换句话说，不管db服务器返回什么，我们都希望在代码级别使用json。（文档数据库的另一种情况。）

• 有可能需要大量的搜索参数和数据，因此索引将是关键，性能将是巨大的潜力。在我看来，这是一个强有力的反对文档数据库的理由

一个潜在的用例将涉及用户调整滑块控件（比如它控制高、低价格参数或距离范围）。然后，所选参数将打包为json对象并发送给搜索控制器，搜索控制器将在更改时将这些参数传递给db服务器，并期望返回一个对象列表。换句话说，用户通常不会按下按钮来优化搜索条件。每次更改参数时都会进行搜索更新

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

我想在我做这件事的时候，我应该问一下关于ORMs的事情。还有一件事我通常不太熟悉（我使用过一点实体框架），但我想知道是否应该扩展我的视野

---

谢谢，我期待着您的意见

我认为您的要求“可能需要大量的搜索参数和数据，因此索引将是关键，性能将是巨大的潜力”，这就为使用关系数据库存储数据提供了强有力的理由

在您的用例中，利用能够支持JSON格式数据的ORM似乎是理想的选择。对于生产中的系统来说，模式演化肯定是一个挑战（虽然不是不可克服的），但最好使用一个ORM产品，该产品至少可以在开发阶段轻松支持模式演化，因为在开发阶段，事情更可能发生变化并快速演化

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

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

这里的“意见”是离题的，这个问题太宽泛了，请不要重新发布问题。