4 ms·
> And the next employee won't know about some random but crucial logic that lives inside Postgres instead of the code. The next employee should know this, beca
by radiator 3y ago
> And the next employee won't know about some random but crucial logic that lives inside Postgres instead of the code.
The next employee should know this, because it will have been documented somewhere.
- ttfkam 3y agoI love Postgres and relational databases in general, but the lack of documentation generation found in general purpose programming languages for the last 20 years is a glaring omission. There simply are no good equivalent to Javadoc for SQL databases. (Except you Microsoft. I see you and MS SQL Server tools. I just don't work on Windows.) You have ERD tools that happily make a 500-table diagram that's utterly useless to humans, are ugly as sin, are not at all interactive, etc. Seriously, Javadoc (and Doxygen, etc.) have been on point since the 1990s. OOP and functional design patterns are common knowledge while 50-year-old relational concepts are still woefully unknown to far too many data architects. Folks don't write docs. They just don't. They start. They agree it's important. But they either get skipped or they stagnate. The only real option is automatically generating. Reading the column and table comments, the foreign key relationships, the indexes, the unique and primary keys, the constraints, etc. and rendering it all into a cohesive and consistent user interface. Not the data. The structure. It's the single biggest tooling failure in that sector in my opinion.