[syats]

Just don't.

SQL:

- does not allow for easy and clean importing of modules/libraries

- is not easily to write tests for

- has limited support for a debugger

- lacks a consistent style for such large queries (plus most textbook cover fairly simple stuff) which means it's hard for a developer to start reading someone else's code (more than in other languages)

- clearly indicates in its name that it is a Query language.

Save yourself the trouble and all your collaborators the pain of working with this code in the future, of trying to add new features, of trying to reuse it in another project.

If you want to operate near the data, use PL/Python for PostgreSQL.

EDIT: Fixed formatting.

[dventimi]

-PostgreSQL extensions are easy to include and use.

-pgTAP exists for testing.

-A large query in SQL is not made smaller but translating it into an ORM DSL.

-If "Query" in "SQL" means it's for querying data, then evidently "Query" not being in say Java or Python means those languages are NOT meant for querying data. If that's true, then why would you use them for querying data?

[nfw2]

> If "Query" in "SQL" means it's for querying data, then evidently "Query" not being in say Java or Python means those languages are NOT meant for querying data

If X then Y does not imply if not X then not Y. Java and Python do not indicate a purpose in their name because they are general-purpose.

[dventimi]

Are they meant for querying data?

[syats]

Re modules/libraries: I meant it is not easy to write a piece of SQL code, and then import it into several queries to reuse it, or lend it to someone else for use on their on schema. It is possible, yes, but seldom done, because it is hell. PostgreSQL extensions could be used for this purpose, but developing an extension requires a different set of SQL statements (or luckily, python or c) than those used by the user of the extension, which makes compounding them a bit hard. Not impossible, just hard to maintain,

About your last point, I don't think that was my line of reasoning, but, yes, for the love of what is precious, don't open SQL files as python/java file objects and then parse and rummage through them to find the data you are looking for. Not impossible, just hard to maintain.

Thanks for pointing out pgTAP, didn't know about this.

For some reason, data-science folks haven't yet caught up with ORMs.. I don't know if this is good or bad, but (as the OP shows) they are more used to rows and columns (or graphs) than objects. Maybe that will change one day.

[dventimi]

> maybe that will change one day

I pray that it never does.

https://blog.codinghorror.com/object-relational-mapping-is-t...

[dventimi]

As for sharing SQL, that's easy to do within a database using views. Across databases with possibly different data models, that's not something I personally ever want to do.

[freilanzer]

Also, there is MindsDB: https://mindsdb.com/