我一直在研究正确的关系代数，来自Christopher Date的书Database in Depth: Relational Theory for Practitioners。在整本书中，他使用他和Hugh Darwen提出的语言来传达理论 - Tutorial D。总的来说，我认为Tutorial D是一种非常可行的查询语言，比SQL更灵活，所以我（只是为了好玩）热衷于编写一个基于Tutorial D的（表现不佳，毫无疑问）小RDBMS，而不是SQL。
认识到这是一项艰巨的任务，即使只是为了制作一些基本的东西，我想知道现有的存储系统是否可用不代表SQL意义上的表，而是代表关系意义上的关系并且不假设任何特定的查询语言都用于访问数据，而只是提供低级函数，如product，join，intersect，union，project等（在C级，而不是在查询语言级别）。
我有道理吗？ :)基本上我想拿这样的东西并在它前面贴一个Tutorial D（或类似的）查询界面。
在内存中做所有事情真的很容易，但是以一种甚至温和有效的方式表示磁盘上的数据结构非常棘手，而且在没有经过一些认真研究的情况下可能会超出我的想法。
答案 0 :(得分：4)
基于SQL的一般RDBMS，使用SQL作为接口，用于用户和数据库引擎之间的结构化输入，使用所谓的Query Optimizer查询表达式并生成一组Execution Plans。
然后在数据库上执行最优的执行计划;这就是生成结果集的原因。
因此，如果您采用开源RDBMS实现并希望修改它以接受不同的查询语言，所有，您必须做的是将您选择的查询语言转换为执行计划。
这并不是说你想要做的事情很简单。只是它应该是可能的，而不必编写自己的RDBMS。您需要为查询语言编写词法分析器和解释器，然后弄清楚如何将解释的查询表达式传递给数据库引擎的优化器，以便它可以生成执行计划，并执行最有效的执行计划。
看一下SQLite作为紧凑的开源关系数据库引擎。
答案 1 :(得分：3)
答案 2 :(得分：0)
请注意，教程D的前端不会与查询语言无关;）
我的投票也适用于Rel。
Hugh Darwen坚持a list of projects related to TTM（D语言的规范，其中Tutorial D是一个实现），我相信如果他们能够做到的话，他会很乐意听到你的努力。