数据对象存储 - 表JOIN可以做单表SELECT不能吗？

Question

现在,像MongoDB或memcached这样的"NOSQL"或"仅对象"存储系统在世界上真正起步.我想知道是否有任何无法对它们执行的请求可以使用多个对象连接执行(在SQL中JOIN "table").换句话说,是否有连续几个单表查询无法处理的多表查询？

基本上,是否存在一个用例,通过在基于对象的存储系统中一次访问一个表,无法复制多表连接？

以下是使用has_man和has_many_through关系的常规3NF查询的一些示例.这些不是最复杂的查询 - 但它们应该为您提供概念的起点.请注意,{}中的任何值表示上次查询结果的值.

---

公司有很多用户

SELECT user.*, company.name as company_name FROM user 
LEFT JOIN company ON company.id = user.company_id
WHERE user.id = 4

VS

SELECT * FROM user WHERE id = 4
SELECT * FROM company WHERE id = {user.comany_id}

---

俱乐部有许多学生通过会员资格

SELECT student.* FROM student LEFT JOIN membership on
membership.student_id = sudent.id WHERE membership.club_id = 5

VS

SELECT * FROM membership WHERE club.id = 5
SELECT * FROM student WHERE id = {membership.student_id}

我想知道的原因是因为我想知道基于对象的系统(依赖于一次访问单个表对象)是否可以执行像PostgreSQL或MySQL这样的RDBMS数据库.

到目前为止,唯一错误似乎是需要更多查询.

Answer 1

1 - 运行多个单独的查询会让您陷入并发混乱 - 当您从表 1 中获取某些内容时，它可能已被删除，并且可能仍在表 2 中 - 现在假设有 5 个相关表。

2 - 对非神秘 ID 的字段运行至少具有中等复杂逻辑的查询

3 - 控制获取的数据量（您几乎不需要超过反序列化/创建有效对象所需的数据的 50％，甚至更糟糕的是连接对象的整个树）

4 - 相关查询（嵌套选择），SQL Server 将像连接一样优化以增加复杂性或更好（|T1|+|T2|+|T3|+|T4|），而任何 ORM 或非 SQL 都必须不断重复内部查询和产生乘法复杂性 (|T1| |T2| |T3|*|T4|)

5 - 数据集大小，可扩展性不仅在于数据集大小，还在于处理更新下的并发性。即使是维护事务的 ORM 也会使事务变得很长，导致死锁的可能性呈指数级增加。

6 - 盲目更新（无缘无故接触到更多数据）及其基于盲目工具的依赖和失败（神话版本，在 1％ 的关系数据模型中实际上需要，但 ORM 和类似的东西必须无处不在）

7 - 缺乏任何标准和兼容性 - 这意味着您的系统和数据将始终面临更高的风险，并依赖于学术冒险主义驱动的软件更改，而不是任何实际的业务责任，并期望在测试中投入大量资源变化。

8 - 数据完整性 - 哎呀，有些代码刚刚从 T1 中删除了今天一半的订单记录，因为 T2 没有外键来阻止它。对于分离的查询来说这是很正常的事情。

9 - 负成熟度趋势 - 不断分裂而不是标准化 - 给它 20 年，也许它会变得稳定

最后但并非最不重要的一点 - 它不会降低任何复杂性（数据之间的相同相关性仍然存在），但它使得跟踪和管理复杂性或在出现问题时难以采取任何现实的补救措施或透明度变得非常困难。并且增加了1-2层的复杂度。如果您的 SQL 表出现问题，您可以使用工具和查询来发现甚至修复数据。当某些 ORM 只是告诉您它有“无效指针”并抛出异常（因为您肯定不想要“无效对象”）时，您该怎么办？

我想这就足够了:-)