我自然是一个前端人物，但数据库设计和后端开发人员在最近几天引起了我的兴趣，我很困惑。我想完全掌握这些概念，所以我的头脑不再受伤了。
我习惯于处理像活动记录这样的ORM。当我通过rails想象我的用户对象时，我想象一个人的对象与人员表中的一行相关。好的基本。
所以，我读到像mongodb这样的非关系型数据库不仅很酷，因为它们“快速处理大数据”但它们也很酷，因为它们显然使用oop语言使开发更自然（为什么？） 。然后我也读到大多数设计模式可能不是真正的关系。好的，这是我迷路的地方。
1）关系设计和非关系设计的一些基本例子是什么？ 2）与上面类似，结构化数据与非结构化的例子是什么（这只是上面的改述？）
所以，鉴于我觉得（在我眼前的无知）这些事情，我试图模仿的几乎所有类型的项目都是关系型的。但也许我只是使用语义而不是技术性。例如，帖子和评论。相互关系。在那里添加用户。现在看来，大多数应用程序都拥有通过其他数据/对象访问的数据。这是关系不是吗？
如何描述不太典型的东西。
假设我正在构建一个锻炼跟踪器应用程序。我有用户，练习，锻炼，例程和log_entries。
我创建了一个分组训练的例程。锻炼是一组练习。我通过练习的日志条目记录我的代表和体重。这是关系数据还是非关系数据？ mongo会非常适合建模或者糟糕吗？
我听到统计数据发挥作用。这对上面的例子有何影响？人们通常会说些什么统计数据？
假设我添加了跟踪其他内容，例如用户体重，身高，体脂等。这对事情有何影响？
感谢您抽出宝贵时间帮助我理解。
编辑：任何人都可以解释为什么一个开发可能比另一个更容易。使用像mongo这样的东西更敏捷，因为它一旦你“ge it”它“点击”更多，而且因为你不需要运行迁移？
另一件事，当使用像ORM这样的抽象时 - 它真的重要吗？如果是这样的话？对我来说，初始值是查询数据和建模对象的简易性。无论是什么让我更容易做到这一点，我会很高兴。我在试图建模数据时真的发现自己在摸不着头脑。
答案 0 :(得分：0)
好的，让我给它一个刺......
（免责声明：我对非关系型数据库的实践经验很少，所以这将有点“以关系为中心”。）
关系数据库使用“cookie-cutters”（表格）来生成大量统一的“cookie”（这些表中的行）。非关系数据库为您提供了更大的自由度，如何塑造“cookie”，但您失去了基于集合的SQL的强大功能。有点像静态与动态类型。
1）关系设计和非关系设计的一些基本例子是什么？
tuple是属性的有序列表，关系是一组具有相同“形状”的元组，表是关系的物理表示。如果某种东西符合这种范式，它就是“关系型”。
金融交易往往是关系型的，而（比方说）文本文件则不然。中间有很多灰色区域。
2）与上面类似，结构化数据与非结构化的例子是什么（这只是上面的重述？）
我不知道。你如何定义“结构化”？
现在大多数应用程序似乎都有通过其他数据/对象访问的数据。这是关系不是吗？
不确定。关系数据库本身没有“指针”，但外键实现了基本相同的角色。您总是可以按照您认为合适的方式加入数据，尽管JOINS通常是通过FK完成的。
假设我正在构建一个锻炼跟踪器应用程序。我有用户，练习，锻炼，例程和log_entries。
看起来这很适合关系模型。
假设我添加了跟踪其他内容，例如用户体重，身高，体脂等。这对事情有何影响？
您可能需要其他列和/或表格。这看起来仍然与我有关。
人们通常会说些什么统计数据？
也许他们在谈论index statistics，这有助于基于成本的查询优化器选择更好的执行计划？
为什么一个人比另一个人更容易开发
正确的工具，还记得吗？如果您事先知道数据的结构并且它适合关系模型，请使用关系数据库。
此外，关系数据库在管理大量数据时非常擅长，许多用户同时访问 （尽管对于某些非关系型数据库也可能如此）。
另一件事，当使用像ORM这样的抽象时 - 它真的重要吗？
ORM往往会让事情变得更容易，更难以处理。再次，这是一个平衡问题。对我来说，能够编写一个精确调整的SQL，可以精确地提取我需要的字段，这绝对胜过了编写样板的CRUD，所以我不是ORM的忠实粉丝。其他人可能不同意。
在试图建模数据时，我真的发现自己在摸不着头脑。
嗯，这是一个很大的话题。如果您愿意花时间和精力，请从ERwin Methods Guide开始，并查看：Use The Index, Luke!