如果关系数据库的正式设计方法是实体关系图，那么 NOSQL 数据库的正式设计方法是什么？
我是数据库设计的新手。据我所知，我们使用实体关系图来帮助设计关系数据库。
如果关系数据库的形式化设计方法是ERD，那么NOSQL数据库的形式化设计方法是什么？
I'm new to database design. As I have learned, we use Entity-Relationship Diagram to help design a relational database.
If formal design approach to relational database is ERD, what is the approach for NOSQL database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您可能会使用实体关系图。仅仅因为您的数据库不像 RDBMS 那样处理数据实体之间的关系，并不意味着您的数据没有关系，只是这些关系是在应用程序中实现的，而不是（非 R）数据库管理系统。我认为了解要存储在数据库中每个条目中的信息仍然是值得的。
如果您想要更定制的东西，那么问题是“NoSQL”是许多不同数据库的总称架构。在确定最佳设计方法之前，您可能需要确定您期望使用哪种 NoSQL 数据库。我认为在几乎所有这些中，您都会想要了解您的实体具有哪些属性，但是，即使您使用的数据库比经典 SQL 数据库具有更大的灵活性（例如键/值对的变量集）
I think you might well use a Entity-Relationship diagram. Just because your DB doesn't handle relationships between your data entities in the way that an RDBMS does doesn't mean your data doesn't have relationships, it's just that those relations are implemented in the application rather than the (non-R)DBMS. I think understanding the information you're going to store in each entry in your DB is still worthwhile.
If you want something more tailored, then the problem is that "NoSQL" is an umbrella term for a lot of different DB architectures. You probably need to determine what kind of NoSQL database you expect to be using before determining the best design approach. I think in pretty much any of them you're going to want to understand what attributes your entities have, however, even if the DB youy are using allows more flexibility than the classic SQL DB (e.g. variable sets of key/value pairs)
对于图数据库，实体关系模型（或其面向对象的表亲，类关联模型）是一个非常好的匹配：这种匹配非常好，以至于我认为图数据库本身就执行这样的模型。
所有其他类型的数据库（包括关系数据库）都要求开发人员“做额外的事情”以将模型映射到数据库。例如，对于 SQL 数据库，额外的内容相对较小（例如，将 NN 关系映射到额外的表、继承的解决方法）。相反，哈希表的额外内容相当大（属性的序列化、关系的手动管理等）。
当然，不同的图数据库连接的无缝程度也有所不同。我参与了一个名为 InfoGrid 的图形数据库，其中从高级模型到代码的步骤是通过代码生成器自动完成的。
For graph databases, entity-relationship models (or their object-oriented cousin, class-association models) are a very good match: the match is so good that I think of a graph database as executing such a model natively.
All other kinds of databases (relational included), require the developer to "do extra stuff" for mapping the model to the database. E.g. for SQL databases, the extra stuff is relatively small (e.g. mapping N-N relationships to extra tables, workarounds for inheritance). On the opposite, the extra stuff for hash tables is fairly large (serializing of properties, manual management of relationships etc.)
Of course, different graph databases also differ how seamless the connection is. I'm involved in a graph database called InfoGrid where the step from high-level model to code is automatic through a code generator.
对于键值存储，使用哈希图，对于图形数据库，使用图形......这些模型应该非常简单，但它们是否像呃模型一样有用是值得怀疑的。
For key-value stores use hashmaps, for graph dbs use graphs... Those models should be pretty straightforward, but it is questionable if they are as useful as er model.