😊, но сделать это смогут далеко не все. Вернее для этого надо будет быть гуру в SQL запросах

я тебе так скажу
лучше всё-таки понимать SQL, когда работаешь с базой данных, а иначе получается как обезьяна с гранатой 😊

всякие orm делают магию, но когда что-то идёт не так...

но это, конечно, право разработчика, учить ему sql или не учить 😊

Honeysql это же не совсем ORM, или я ошибаюсь?

насильно никого не заставишь

это не orm, да
я говорил про всякие генераторы sql, хотя не знаю, все ли они являются orm

скорее правильнее говорить о dsl и не dsl

Похоже надо оба варианта попробовать, чтобы понять что подойдет😊

Интересно, я обычно группирую по сущностям. 1 сущность – 1 файл, но много запросов.

Ну это вообще когда надо, а на начальном этапе можно вообще все в одном файле накидать, если не сильно много

Разбиение по мере надобности

по сущностям я группирую в наименованиях
типа как-то так

login.find-client-api-token.sql
login.save-client-api-token.sql
login.update-client-api-token-introduced.sql
maintenance.delete-client-api-token-deleted.sql
maintenance.list-google-lost-order.sql
maintenance.list-payment-transaction-failure.sql
maintenance.save-payment-transaction-refund.sql
maintenance.update-payment-transaction-failure-resolved.sql
payment.find-payment-database-for-new-transaction.sql
payment.list-payment-product-by-config.sql
payment.save-payment-provider-log.sql
payment.save-payment-transaction.sql
payment.save-payment-transaction-failure.sql
payment.update-finance-overview.sql

заодно в историю изменений хорошо ложится

ну, разделять муторно, когда в одном файле становится неудобно
поэтому если фреймворк сложился, то проще придерживаться стандартной схемы

Мне бы для такого пришлось бы писать много конфигов, что я не очень люблю. Особенности duct

у меня «конфиг» для запросов выглядит так
https://github.com/serioga/webapp-clojure-2020/blob/206b0ff1d38edec506c9850e30685d50b2ff9af7/src/app/database/core.clj#L73-L76

да вроде совсем просто

select * from payment_product
where (:keyword IS NULL OR keyword = :keyword);

Не, я в плане того, что там ещё баундари, для сущностей есть, и прикидывать по одному запросы неудобно, а так сделал map-of-db-fns, и все нужные запросы попали куда надо

https://github.com/duct-framework/duct/wiki/Boundaries

В итоге конфиг будет типа

{:query/some “file1.sql”
:query/another “file2.sql”
 ....
:boundary/some {:queries {:some #ig/ref :query/some}}}

Где-то около того