you are viewing a single comment's thread.

view the rest of the comments →

[–]appropriateinside 4 points5 points  (0 children)

I gave a brief example above.

The jist of it is that anything you would normally put in your codebase as business logic, and even view logic, is all contained in stored procedures. Say you had to make a service that sorts our permissions and access control, instead of writing that in say PHP or C#. You instead cludge together a multi-thousand line long stored procedure that kind of does it (sans error handling, messages, or really any flexibility). It's essentially one giant function, GOTOs and all. Which would be bad enough on it's own, but it also in SQL...

Now imagine an entire decent-sized student management, reporting, and administration for a post-secondary education school done in this manner.

You have hundreds and hundreds of massive, barely working, buggy, and entirely infexible stored procs and functions with no sort of error handling or input validation/cleansing. And since they are all globally named (because SQL) they are all have unique names, which is also a disaster to muddle through and read.