我们的项目正在寻求建立一个大型数据库，我正在寻求研究我们实施的术语，技术和/或技术。我怀疑我们的项目是什么新东西，但是想要利用那里的常规做法（而不是从头学习）。
我们项目的一个设计但非常适用的例子是这样的层次结构：
将会有一些出版社（订单总数为10）
PublishingHouses将拥有发布者（订单总数为100）
作者将拥有书籍（订单） 10000，总计）
将有读者，他们将对书籍进行记录/审查（订单 5M，总计）
我们系统的常见报告项目是发布者或作者登录系统并收集读者的评论。诀窍是，他们必须只能看到与他们控制的图书相关联的读者。
我们担心的是，报告操作的每个查询都必须筛选5M阅读器评论，以了解它们是否与相关的PublishingHouse，Publisher，Author和/或Book匹配。
最适合解决此问题的术语，技术和/或技术是什么？你能解释为什么那会适用于我们的问题集吗？我有更多的研究要做，但希望你的经验和答案能指出我们正确的方向。
谢谢！
（仍然需要更多信息，但我目前的解决方案是将一些表格用于PublishingHouses到发布者，发布者到作者，作者到书籍以及在找到读者时使用级联JOIN以确保我有正确的设置。我听说过谈话关于可能适用于此处的“观点”。）
答案 0 :(得分：1)
听起来像是关系数据库（MySQL，Oracle等）的经典用例。我不会太担心有5M行，如果查询列被索引（即你使用一些额外的磁盘空间但是快速查找），你将能够搜索和加入没有问题。
如果您的'订单'价值在正确的球场，那么您正在查看10,000,000,000本书，所以这将是您的主要尺寸问题。每次审核只有1000个字符，您可以单独查看10TB的数据。在这种规模下，可能值得开始研究Hadoop / Hbase等“大数据”解决方案。但是，这些通常不会针对快速查找进行优化，而且更适合批量作业分析，因此需要对所需内容进行一些调整。
希望有所帮助！