In today's words, "flowcharts" means "code" and "tables" means "data structures".
I don't care if it is:
- tables in a relational database
- nested structs (records) and lists
- nested dictionaries (hash tables) and lists
- JSON
- XML
- ... whatever
What I do care is that I can see the data structures, and not just the code. Static typing often gets that job done fairly well. If you don't use that, please use at least type annotations. This is the most important part of your documetation, and the compiler ensures it remains correct over time. Most of the time, this (+ the function name) is the only documentation I really need.
Show me your well defined normalized tables and I have all I need.
But for the love of $entity please don't show me tons of business logic in stored procedures. I actually won't work for a company that expects me to build or maintain a product based on stored procs.
* it is easily unit tested
* all source code is one place that can be branched, versioned, merged, deployed, rolled back, diffed, code reviewed, approved with pull request etc.
In which case the stored procedures are in your "main" code repo and "deploying" them simply means running the software. Though your point about unit tests stands.
Table schema is the hard part since there is overhead associated with creating an index on an existing table and with renaming a column.
How do you handle 5 - 10 devs working concurrently if they are all running tests?
You can run unit tests by creating transactions, running the test, and then rolling back at the end.
I do get your point, though. It's more convenient to be able to mock your database from your code.
https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113)....
Go down to "Testing Query Scenerios". I've wrapped the four "mockset.As" lines into one extension method to make it a lot less verbose.
context.Database.Log = log.Info
Where Log.info is just a method that accepts a string and take a look at the log file generated from your unit tests.
pgtap lets us unit test our SQL functions, triggers, views, etc. It's integrated with our change management system. It's fast enough and works well.
It's the same as other code, but with better data locality.
Please note that the quote uses old language. With "flowcharts" they actually meant what we know call "structured code".
More precisely, the flowcharts were the hand-written program which was then translated into machine code or some kind of assembly. In other words, back then the flowcharts were the highest level code.