我真的应该将所有不同类型的数据放在一个数据库中吗?

发布于 2024-12-01 13:15:28 字数 397 浏览 0 评论 0原文

引自 CouchDB 指南

MapReduce 可能具有挑战性,特别是如果您多年来一直在使用关系数据库。

我正是处于这种情况。不同之处在于,对我来说,这不仅适用于 MapReduce,还适用于 schemafree'ish 数据库的整个概念......;)

我是否真的可以自由地将所有数据放入同一个数据库中,无论它们有何不同(用户、会话等)?由于视图在数据库级别工作,我知道我应该(需要?)。

PS:我知道这是一个非常不具体的问题,这取决于具体需求......:)

Quote from CouchDB guide:

MapReduce can be challenging, especially if you’ve spent years working with relational databases.

I'm exactly in that situation. With the difference that for me this applies not only for MapReduce but for the whole concept of schemafree'ish databases... ;)

Am I really free to put all my data in the same database, regardless of how different they are (users, sessions, etc.)? Since views work on database level I understand that I should (need?).

PS: I'm aware that this I a pretty unspecific question and that it depends on the specific needs... :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

肤浅与狂妄 2024-12-08 13:15:28

对于原型设计、学习 CouchDB 或其他早期项目,我建议您将所有内容都保存在同一个数据库中。保持简单。专注于构建软件。

随着项目的发展,何时扩展到更多数据库将是显而易见的。

如果您的应用程序的用户将直接连接到 CouchDB,则有两个注意事项:

  1. 用户帐户已位于名为 _users 的单独数据库中。 CouchDB 使用它来确认密码并处理身份验证
  2. 访问控制(特别是读取数据的权限)在数据库级别进行控制。用户可以完全读取数据库,也可以根本不读取数据库。当您的应用程序开始维护每个用户的私有数据时,这是创建多个数据库的好情况。

有时,用户从不直接连接到CouchDB。考虑具有 Web 服务器前端和数据库后端的传统 3 层应用程序堆栈。与 MySQL 或任何其他数据库非常相似,从 CouchDB 的角度来看,您只有一个数据库用户:Web 服务器。在这种情况下,拆分为多个数据库在很大程度上是一种优化,可以推迟到需求明确为止。

For prototyping, or learning CouchDB, or otherwise early-stage projects, I suggest that you keep everything in the same database. Keep it simple. Focus on building the software.

As your project evolves, it will be obvious when to expand into more databases.

If your application's users will connect directly to CouchDB, there are two considerations:

  1. User accounts are already in a separate database called _users. CouchDB uses this to confirm passwords and handle authentication
  2. Access control (in particular, permission to read data) is controlled at the database level. Users can read a database either completely, or not at all. When your application begins to maintain private data per user, that is a good situation to create multiple databases.

Sometimes, users never connect to CouchDB directly. Consider a traditional 3-tier application stack with a web server front-end and a database back-end. Much like MySQL or any other database, from CouchDB's perspective, you have only one database user: the web server. In that case, splitting into multiple databases is largely an optimization which can be postponed until the requirements are clear.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文