… 我经常提到这一点，但在研究面向数据的设计（Mike 所说的内容）时，我发现了 Richard Fabian 的面向数据设计书籍[1]，其中大量讨论了数据库规范化等内容。我觉得这很奇怪，因为他在讨论的低层次高性能游戏代码显然不会将数据编组到数据库中以运行 SQL 查询。但事实证明，关系模型有很多优势。程序员经常使用树结构，比如在面向对象编程中，在结构体中包含结构体，在对象中指向其他对象。很容易忘记树只是图（即网络）的一种特殊情况，而且有很多表示网络的方式，而不需要直接编码树结构。因此，我一直在按照 Richard Fabian 的建议去做，把我的数据（在纸上）整理成表格，然后尝试进行规范化，看看其中的联系。我真的喜欢这种设计方式。…
源讨论代码重复比错误的抽象要便宜得多原帖 354 条评论 · 导入时统计> Mike 的演讲认为，代码解决方案不必以现实世界为模型，不同的数据会产生不同的问题，需要不同的解决方案。 我总是觉得奇怪，即使是一些相当聪明的工程师，有时也会优先考虑现实世界的隐喻，而不是代码库的实际需求。几年前，我刚毕业几年，正在用 Rust 实现一个连接池，当时最合理的方式是让连接持有对池的弱引用，这样在连接被释放时可以自动归还。我的经理（一位经验非常丰富的工程师）不喜欢这个想法，因为他认为“图书馆的书由图书馆持有，而不是反过来”。我觉得这并不是一个令人信服的理由来改变设计，但他拒绝以任何其他方式看待这个问题，只从这个隐喻的角度来看。最终，i…
完整原文把你的经验，加入这段讨论。
> 我的主要问题是，在大多数编程语言中进行类似数据库的操作非常麻烦，如果你真的想尝试将数据序列化到一个真正的数据库（比如通过库使用SQLite或DuckDB），那么你就会有一个巨大的混乱的转换层，你试图将各种东西匹配到SQL类型，而且到处都是巨大的SQL字符串。 听说过Java的JOOQ库吗？它是一个福音，因为你可以用纯Java编写保证类型安全的SQL——没有任何语法糖。我预计LINQ在C#中也能做到这一点。
完整原文这一直是我在过去很多年里经常思考的问题，这在一定程度上是因为我之前提到的连接池工作是在我刚毕业的前几年做的，当时我在MongoDB工作，参与了他们的一些数据库客户端库。我知道在互联网的这些地方，MongoDB经常受到很多批评（至少在技术观点上，我认为其中有些是合理的，有些则比网络争论所表现的要更复杂一些，还有一些只是早期的一些遗留问题，而这些在过去十年里人们所使用的任何数据库版本中都已经不再适用了），但有一件事我一直觉得很有意思，就是它如何改变了你所描述的那种体验，使其变成一种大部分工作都在于找出最佳数据模型的体验（你必须关心诸如“如何”之类的问题）…
完整原文> 我的主要问题是，在大多数编程语言中进行类似数据库的操作非常麻烦，如果你真的想尝试将你的数据转换成真正的数据库（比如通过库使用 SQLite 或 DuckDB），那么你会有一个巨大的混乱的转换层，你试图将事物与 SQL 类型匹配，并且到处都是巨大的 SQL 字符串。 我更喜欢在它是面向领域的时拥有这个转换层。所有的 sql 字符串都被收集在一个隔离的模块中，唯一导出的符号是一组函数。 从领域驱动设计的角度，我学到的是要习惯在不同层/子域中对同一数据有不同的表示形式。某物可能来自 API 的一个胖对象，但我更喜欢有一组函数，每个函数使用不同的部分，并有一个缓存层来避免实际进行昂贵的网络调用。这个网络调用和缓存层将会…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。