项目管理 Web 应用程序：关系数据库还是面向文档的数据库？
有很多帖子讨论关系与文档数据库，但它们都非常通用。
我想通过一个具体的例子来理解它们的差异。
假设我们正在构建另一个面向 Scrum 的项目管理 Web 应用程序。
虽然我们想尝试一项新技术，但我们不想仅仅为了做一些炒作的新东西而牺牲设计并增加整体复杂性。我们希望做出正确的决定，即使这意味着使用旧技术。
因此，想想 PivotalTracker。我们将存储项目、故事、故事评论，可能是罕见的附件，也可能是子任务（故事分为实际任务）。
还支持迭代，因此每个任务实际上属于一个项目并且可以迭代。在迭代内部，任务需要按特定顺序排列。用户可以通过上下拖动来重新排列故事。
对于每个故事，我们还希望使用单独的时间条目来跟踪其花费的时间。
我可能想生成报告，但没有什么太花哨的（燃尽，也许与时间相关的东西）
您会使用哪个数据库，关系数据库还是文档数据库？或者其他的？为什么？
你会如何设计它的结构？例如，如果您要使用文档数据库，您会进行标准化吗？
There're quite a few posts discussing relations vs document databases, however they are all quite generic.
I'd like to understand their differences in a specific example.
Let's imagine we're building another scrum-oriented project management web app.
While we'd like to experiment with a new technology, we don't want to sacrifice design and increase overall complexity just to do something new that's hype. We want to make the right decision, even if that means using an old technology.
So, think of PivotalTracker. We'll be storing projects, stories, story comments, maybe rare attachments, and maybe sub-tasks (story split into actual tasks).
There's support for iterations as well, so each task actually belongs to a project and can be in iteration. Inside iteration, tasks need to be arranged in specific order. User can rearrange the stories by dragging them up and down.
For each story we also want to track time spent on it, using separate time entries.
I might want to generate reports, but nothing too fancy (burndown, maybe something related to time)
Which DB would you use, relational or document? Or some other? And why?
How would you design its structure? For example if you would use document DB, would you normalize at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
NoSQL 和关系数据库之间的基本权衡在于报告功能。对于关系数据库，这是通过集合操作来完成的，并且关系数据库通常对于报告确实进行了很好的优化。这需要严格的模式，以便数学正确运行。对于 NoSQL 数据库，这是通过 MapReduce 完成的，分布式计算和灵活的模式会阻碍这一点。从本质上讲，使用 NoSQL，您的报告始终是专门构建的，并且几乎不存在临时报告。出于这个原因，我支持这样的想法：始终从 RDBMS 开始，然后根据需要添加 NoSQL 附件。
对于项目管理尤其如此，企业主可能希望不时提出新的报告。
The basic tradeoff between NoSQL and Relational DBs is in the reporting capabilities. With relational databases, this is done with set operations and relational dbs are really very well optimized for reporting generally. This requires rigid schemas so that the math works right. With NoSQL dbs this is done via MapReduce, and distributed computing, and flexible schemas get in the way. In essence with NoSQL, your reporting is always purpose-built and ad-hoc reporting is virtually non-existent. For this reason I a fan of the idea that you should always start with an RDBMS and then add NoSQL adjuncts as needed.
This is particularly true with project management where business owners may want to come up with new reports from time to time.