Why not just design a generic ORM based on views and stored procedures?

[deahhh]

1. view is the interface for relational database
2. stored procedure is the interface for relational database too
3. stored procedure is pre-compiled, so can be more efficient
4. stored procedure is flexible enough, which could take advantage of the database features more fully.
5. only work to do is parse data to be translation and translated.

BTW, is it implemented?

[essenciary]

These are just features that are part of an ORM, I don't understand how the current codebase is exclusive to these and why would they require designing something else vs just adding support for stored procedures for example (views should already work?).

Also "why not"? I recommend you do some research into problems with using stored procedures. I don't want to go over what's already been discussed at length and you can find online, but a few things that come to mind based on my research years ago are:

• introducing code/logic into the database
• non-portable (one of the core features of an ORM is to allow swapping database backends, you can't do this if you code into the database)

[deahhh]

Thanks!
I just don't know how to do it yet, I guess.
But, the Documentation is too limited to help.
I read some resource while debugging, find nothing about how to realise that.