我认为对于这个问题没有唯一的正确答案。但我建议您考虑以下内容......您决定使用关系型数据库（我认为这是完全可以的！）......因此，有人可能会说......首先，您的问题与ER建模等有关，而不仅仅是关于Clojure（:-）.....
......我的意思是什么？嗯，您已经提到了ORM。当您用Java做Java时，关系世界和OO世界之间的“阻抗/范式不匹配”，往往会导致大量杂乱和无头绪等问题。
好吧...但是对于使用对象关系映射器（ORM）而言，你需要付出的代价是巨大的（我认为是这样）。比如说，如果你在做事情时不够小心，Hibernate 这样的工具可能会给出非常疯狂的事情/查询...例如，当你天真地获取某种树结构时，生成的 SQL 可能会很荒谬...显然，Hibernate 非常强大...你可以集成非常复杂的缓存等等等等...但是...要想用得好好/正确地使用 Hibernate 并非易事/直接的事...我觉得。
所以...即使是做 Java，我建议首先考虑 Spring JDBC 数据访问...因为...正如我所说...JPA 肯定会带来不少复杂性...(因此，问问自己你是否真的需要 JPA)
...无论如何...我想说的是...关系数据库很棒...SQL 很棒...PostgreSQL 也很棒!!!许多编程语言的麻烦在于与关系技术交互往往非常痛苦...因此，你需要构建各种工具，如 ORM 等，以使你的生活更容易忍受...(所以我们谈论的是治疗方法，而不是治愈方法)
...现在，我想说的是，使用 Clojure 相比之下，整个不匹配问题要轻微得多，因为 Clojure 不是围绕 Person 等类构建的，而是你有一些强大的集合，你就可以出发了 :-)...
...所以让我们来具体谈谈...我已经使用 Clojure(script) 创建了这个闪卡 SAP...
...现在...有很多事情我不太满意...例如，我真的想从 Bootstrap 转到 Bulma 等...这是我做的第一个非平凡的 Clojure 项目...因此，显然我犯了很多错误...我会尽快尝试重构/改进 things...然而，主要的观点是我最不担心的是 PostgreSQL / RDBMS 部分...
....我用 luminus 模板设置 PostgreSQL 项目...这个设置包括 hugsql（拥抱 SQL 的 Clojure 库）....然后你可以做你的 dd l / 模式事宜...你的 PostgreSQL 查询...存储过程等等...以一种完全独立于任何应用程序编程语言的方式进行...只需使用你的 PostgreSQL 工具/知识即可...这有多么伟大!!!!...另外，比如说，如果我想从 Clojure 切换到 Java / Node 等等...我的整个数据库/持久层东西可以基本上保持原样...因为使用 hugsql 你做的就是 SQL...再加上非常少元配置的东西，你将其放入注释中...通过这些注释，你会得到可以运行查询的 Clojure 函数...你可以将这些 prepared 语句的参数以 map 的形式传递...并得到一个 map 的输出，一个记录或 n 个记录的记录序列...以及 nil，如果你没有记录的话，我想。
在进行转换等操作时，你拥有所有基本的但强大的Clojure函数，它们使处理映射和序列变得轻而易举。另外，总会有一些类型转换的内容，例如从PostgreSQL转换为Java，从Java转换为JavaScript。但是，如果你使用Luminus，你将能够直接获得这些辅助工具。例如，在我开发的闪卡应用中，有很多时间戳（例如你何时回答了某张卡的答案，何时留言等）。而日期类型一直以来都颇具挑战性——java.sql、java.util、joda等。但在开发这个应用时，我真的不用为这些担心，因为Luminus会为你处理一切。同样，使用优秀的Clojure（脚本）时间库（https://github.com/dm3/clojure.java-time / https://github.com/andrewmcveigh/cljs-time），你可以编写与时间相关的代码，并且这些代码无论在中间件还是前端都会运行良好（...当然有细微的例外...）。另外，Luminus也提供了需要的transit-adapter（不确定是否真的叫这个名字）相关功能！
无论如何，我采用了这“最少即多”的策略，对此我相当满意。无论你对此有何看法，都请随意吧！:-)
