It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
It's an interesting idea with some clear potential benefits, but I think your choice of DDL for an example doesn't do it justice at all. As you point out, comment on means it's already easy for schemas to explain themselves. More specifically, copy like "the users table tracks the users of our application" adds nothing whatsoever to create table app.users, and your commentary on the hash trigger and login function mostly talks about how triggers and functions work in the abstract -- in other words, content already covered by the database documentation itself.
Schema setup just doesn't get much out of a literate SQL style compared to, say, individual queries, or view/function bodies. Show off some monstrosity full of CTEs, unions, and subqueries sticking out at odd angles made comprehensible by interleaved commentary and you'll have made your point much more effectively.
Yes, the DDL example is not ideal... I'm looking to make a tutorial out of it for new PostgREST users that don't have a lot of experience with Postgres, so it's more verbose than it should be in a normal application. Let's see if I can dig up a more monstrous example with CTEs somewhere. And please let me know if you have something sufficiently convoluted at hand! :-)
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
It's an interesting idea with some clear potential benefits, but I think your choice of DDL for an example doesn't do it justice at all. As you point out,
comment onmeans it's already easy for schemas to explain themselves. More specifically, copy like "theuserstable tracks the users of our application" adds nothing whatsoever tocreate table app.users, and your commentary on the hash trigger and login function mostly talks about how triggers and functions work in the abstract -- in other words, content already covered by the database documentation itself.Schema setup just doesn't get much out of a literate SQL style compared to, say, individual queries, or view/function bodies. Show off some monstrosity full of CTEs, unions, and subqueries sticking out at odd angles made comprehensible by interleaved commentary and you'll have made your point much more effectively.
Yes, the DDL example is not ideal... I'm looking to make a tutorial out of it for new PostgREST users that don't have a lot of experience with Postgres, so it's more verbose than it should be in a normal application. Let's see if I can dig up a more monstrous example with CTEs somewhere. And please let me know if you have something sufficiently convoluted at hand! :-)
How's this?
Deliciously monstrous! Only missing some 'with recursive' to round it off :-)
Let's use that as an additional example! Thanks Dian.