问题标签 [non-relational-database]

我正在构建一个大型网络应用程序，它将帮助“区域经理”管理多个地区的多所学校。

总共有大约400,000名学生和教师。

除了管理成绩等显而易见的事情之外，我们还必须管理出勤率（每天）。

我习惯于以较小的规模构建 Web 应用程序，并将其部署到 Heroku。鉴于这种规模的系统，我应该考虑从现在开始使用非关系数据库，还是应该坚持使用 PostgreSQL 并进行特定优化以确保高速和数据完整性？

如果不清楚，主要问题是系统在管理这么多表中的这么多记录时速度太慢 - 在关系数据库系统中。

另外，如果建议使用关系数据库，我可以做哪些常见的优化来确保速度？最大、最明显的一个是对最常访问的信息使用索引......其他类似的东西将不胜感激。

谢谢。

PS 我的团队在我们应该做什么方面存在分歧，所以你们会发出有用的声音来帮助平衡:)

我的工作中有一个 Django 应用程序，只能在内部网络上使用。

目前我们使用 Excel 导入数据，但这是一个非常容易出错的过程，我想替换它。

我想在 Javascript 中提供一个丰富的 Web 应用程序，它公开了来自主 Django 应用程序的一些但不是全部数据（菜单的查找值）。这将在对外界可见的服务器上运行。

那么有什么好的方法呢？

管理层担心将主 Django 应用程序提供给外部世界的安全性，我也更喜欢中间层 - 我认为编写一个小型服务器端应用程序比检查当前代码并确保更容易它对外界来说足够安全（我学习了 Django 构建这个应用程序，所以一些旧代码没有按照最佳实践完成，但确实可以按需要工作）。我还希望它保留新数据，直到有人在导入主数据库之前检查它看起来不错。（我是唯一的开发者，所以有时间考虑）。

所以我现在能想到两个选择。

1：在面向外部的服务器上有一个小型 Django 应用程序。这可以与主应用程序通信以获取查找所需的值，并在导入之前存储输入。这些表将基本上反映主应用程序，并在主应用程序表更改时需要更新。

2：有类似的东西，但不是使用数据库，而是使用面向外部的服务器来联系内部服务器上的 REST 接口。类似于使用 Django 非关系从主应用程序的 REST 接口获取数据。在主数据库服务器中放置一个导入表以存储数据以供审批。

这些方法是好还是坏？还有其他建议吗？有没有学习 n 层应用程序的好资源？

我的 mongoDB 集合中的所有文档都有一个整数数组。对于每个整数，我不需要超过 32 位，并且整数数组的长度对于每个文档都是相同的。

我的应用程序的客户端将经常更新数组中的各个字段。

如果我有 5000 到 10000 个包含 256 个整数数组的文档，mongo db 是否会浪费空间，因为我需要准备好将数组的内容更改为非整数数据类型，或者更改数组的长度？

与传统的关系数据库相比，mongoDB 的设计是否会使更新数组中的单个整数非常低效？

假设我正在使用此处描述的更新数组语法：http: //docs.mongodb.org/manual/applications/update/#update-arrays

我正在使用 MongoDB，最终得到了两个集合（无意中）。

第一个集合（样本）有 1 亿条记录（推文），结构如下：

来自推文集合的第二个集合（用户）有 3000 万条唯一用户记录，它看起来像这样

其中 users 集合中的 _id 是 tweets 集合中的 user.screen_name ，目标是他们的状态（是否是垃圾邮件发送者），最后 value.count 是用户出现在我们的第一个集合（样本）集合中的数量（例如 number捕获的推文）

现在我想进行以下查询：

我想从用户的目标值 = 1 的示例集合（推文）中返回所有文档

换句话说，例如，我想返回所有垃圾邮件发送者的所有推文。

我会尽量做到直截了当。
来自 MySQL 并从表的角度思考，让我们使用以下示例：

假设我们有一个房地产网站，并且我们
正常显示房屋列表，我会使用下表：

• 房屋 - 手头的房地产资产
  
• owner - 房屋的所有者（与房屋的一对多关系）
  
• 代理机构 - 房地产经纪人机构（与房屋的多对多关系）
  
• 图像 - 与房屋的多对一关系
  
• 评论 - 与房屋的多对一关系
  

我知道 MongoDB 让您可以灵活地在具有唯一 ID 的不同集合中设计 Web 应用程序，就像关系数据库（规范化）一样，并且为了享受快速选择，您可以嵌套在集合中，相关对象和数据（未规范化）。

回到我们的房地产列表，用于填充它的查询在普通关系数据库中非常昂贵，对于您需要查询其图像、评论、所有者和机构的每栋房屋，每个实体都位于具有其字段的不同表中，您可能会使用连接并将多个查询合并为一个 - 昂贵！

进入 MongoDB - 您不需要连接，您可以将房屋的所有相关数据存储在房屋集合上的房屋项目中，选择从未如此快，这是一个 db 天堂！
但是当您需要添加/更新/删除相关评论/代理/所有者/图像时会发生什么？

这对我来说是个谜，如果我需要猜测，每个相关的集合都存在于自己的集合中，位于房屋表中的数据之上，一旦添加/更新/删除这些相关数据中的一个，你必须在其自己的收藏以及房屋收藏上对其进行更新。在此更新后 - 我是否还需要查询其他集合以确保我正在使用所有更新的相关数据更新房屋记录？
我只是在这里猜测，非常感谢您的反馈。

谢谢，
Ajar

我正在寻找连接到非关系数据库 IMS 的工具。有没有可用的工具？类似于关系数据库的 DBVisualizer。

请对元数据 URL 有想法的人告诉我，当我有主机名、端口和 IMS 数据存储时，如何找到元数据 URL？

我得到了有关元数据 URL 的以下信息：

表示目标 IMS 数据库的数据库元数据的位置。

MetadataURL 属性是由 IMS Enterprise Suite Explorer for Development 生成的 Java 元数据类的完全限定名称。URL 必须以 class:// 为前缀（例如，class://com.foo.BMP255DatabaseView）。

意识到这个讨论，有一个额外的旋转。

目前在我们组织的工程师之间辩论标题问题。

一方面，有人认为将非关系数据库（即 CouchDB）连接到生产服务器绝不是一个好主意。他的架构建议是引入一个中间关系数据库作为两者之间的一种缓冲层（他特别推荐 SQLAlchemy 作为 Postgres->Flask/Django 之类的 ORM）

另一方面，另一位工程师认为，鉴于我们的（相对较低的）页面浏览量，我们可以在 CouchDB 中将整个事情直接投入生产。

我很想了解更多关于nonrelational -> relational -> web page架构与只是nonrelational -> web page.

我是任何类型的数据库的新手。似乎您可以以图形形式表示任何关系数据库（尽管它可能是一个非常平坦的图形），以及关系数据库中的任何图形数据库（具有足够的表）。

通过从一个条目到另一个条目的硬链接，图可以避免在其他表中进行大量查找，因此在许多/大多数情况下，我可以看到图的速度优势。如果您的数据是自然分层的，特别是如果它形成一棵树，我会看到图表优于关系图的逻辑/推理优势。我想象一个链接到其他节点的图节点可能包含多个地图或列表......它实际上包含一个图节点内的关系数据库。

图数据库与关系数据库有什么缺点吗？（注意：我不是在寻找诸如在实现中缺少功能之类的东西，而是在理论上的优点/缺点）

我什么时候还应该使用关系数据库？即使我在逻辑上有一个从 int 到 int 的映射，我也可以在图中完成。

我正在寻找最佳实践，将工作日存储在mongodb文档中。

在关系数据库中，1-n nn关系意味着 2 个或更多表。但是在非关系型数据库中，由于可以将这些东西直接存储到一个模型中，我想查询周二所有可能的时间表：