Hacker News Reader

Comment by Nican | Hacker News Reader

It was not the first time I heard the requirement about "all data access happen through stored procedures", and I find it ludicrous.

Does anyone know how such a paradigm came to exist? What problem is this solving?

View on HN

I remember it being common in the 90s and 2000s, when DBAs were primarily developers.

It's absurdly overkill if you're just doing CRUD, but if the DB uses some crazy schema that doesn't match the usage it keeps you sane.

One such project I worked in had a primitive form of event sourcing built in. Everything was logged and could be replayed. It was kinda neat.

Security, decoupling calling code from db schema

Don't API services do that?

How do they do that in the context of ORM vs sps :)?

Calling code is the front end... API services separate that calling code from the backend.

your backend is still storing data somewhere right?

Yes, but I'm not sure I get the benefit of decoupling the schema, I'm still coupling to the stored procedure interfaces, and still have to deal with the shape of input and results.

If schema needs to be changed in many cases sp interface will stay the same e.g. I can do changes/optimizations to schema without changing the calling code.

But, if it's a schema change where you have to update the SP, you still have to change code... it's that the code is in (PL/T)SQL vs in another language.. You still have to update code either way.

Same as a rest api

Reply on news.ycombinator.com