【发布时间】:2019-06-20 05:01:36
【问题描述】:
我知道这是一个令人作呕的话题,但我也知道有些人喜欢对数据库发表意见,所以我想我还是继续问这个问题。
我正在构建一个 Web 应用程序,它在非常基本的级别上显示满足用户定义的搜索条件的对象列表。该应用程序的主要功能是提供一个界面,用户可以通过该界面对大量对象属性(包括数据范围、位置数据和可能的相关数据)执行实时分面搜索。
当然还会有辅助信息:用户帐户、查找表等。
我的背景完全是关系数据库开发,主要是 SQL Server 和一点 MySQL。但是,我对对象关系方法甚至完整文档数据库的可能适用性很感兴趣。如果没有在这些范式中工作的经验,我不确定自己会陷入什么困境。
以下是一些可能会影响决定的进一步考虑因素:
随着时间的推移,随着更多属性和搜索选项的添加,架构可能会发生相当大的变化,从而产生典型的版本控制/部署挑战。这是我考虑使用文档数据库的主要原因。
应用程序本身可能会在 Node/Express 中使用 Typescript 使用 Angular 或 React 前端编写,因此代码将与 json 格式的数据进行交互。换句话说,无论从 db 服务器返回什么,我们都希望在代码级别上使用 json。 (文档数据库的另一种情况。)
可能存在大量搜索参数和大量数据,因此索引将是关键,性能将是一个巨大的潜在问题。在我看来,这似乎是一个针对文档数据库的有力案例。
一个潜在的用例将涉及用户调整滑块控件(假设它控制高低价格参数或距离范围)。然后将选定的参数打包为 json 对象并发送到搜索控制器,然后搜索控制器将这些参数在更改时传递给 db 服务器,并期望返回一个对象列表。换言之,用户通常不会按下按钮来细化搜索标准。每次更改参数时都会发生搜索更新。
我不知道这件事在多大程度上是一件好事,但如果有某种方法可以利用可以缓存搜索结果的技术,然后在搜索范围缩小时在这些结果中搜索,那就太好了,因此仅对第一次搜索的较小子集执行第二次搜索,而不是对可用对象的整个宇宙。
我想我应该问一下 ORM。还有一些我通常没有经验的东西(我使用过一些实体框架)但想知道我是否应该扩大我的视野。
谢谢,期待您的意见!
【问题讨论】:
-
“Opining”在这里是题外话,这个问题太宽泛了,请不要重新发布问题。 How to Ask
标签: database orm relational-database document-database