Home/ Questions/Q 7016519
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T22:47:45+00:00

In reading @PerformanceDBA’s answer to Historical / auditable database he made this statement: In

  • 0

In reading @PerformanceDBA’s answer to Historical / auditable database he made this statement:

In a real (standard ISO/IEC/ANSI SQL) database, we do not GRANT
INSERT/UPDATE/DELETE permission to users. We GRANT SELECT and
REFERENCES only (to chosen users) All INSERT/UPDATE/DELETEs are coded
in Transactions, which means stored procs. Then we GRANT EXEC on each
stored proc to selected users (use ROLES to reduce administration).

Is this true? How does that jive with ORM tools which generate INSERT/UPDATEs dynamically?

UPDATE

OK, so here’s an example. I’ve got a web application with two interfaces, an Admin and a User. The admin side uses heavy ORM capable of generating hundreds if not thousands of distinct SQL commands dynamically.

The user interaction is far simpler, and I’ve got a dozen or so SPs that handle any UPDATE/INSERTs for a couple of voting buttons. Obviously the users the applications run under have very different permission sets. On the admin side the DB user for the ORM has full CRUD access to relevent tables, there are no SPs used at all for this application–and I wouldn’t think of touching the data without going through the business logic in the domain model. Even bulk data imports get processed through the ORM. SPs on the user side I consider a small concession to this principle just because they are such a special case.

Now, I find the statement above in the original question somewhat disturbing, as I’d consider this to be something of a ‘real’ database, or at least close to it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It jives like your grampa at a rave. ORMs can utilize SPs but it doesn’t get the best out of them.

    SP Only was certainly the way life used to be, it was like the eleventh commandment, but as you point out ORMs don’t really work like that. I used to think of the whole SP layer as a sort of prepubescent ORM in itself, you took your relational DB, made a bunch of joins and returned a set of data with the columns/properties needed to populate your objects with.

    These days, with dynamic ORM type apps, permissions need to be specified on the table, it’s no less secure if your DBA is doing their job, it’s just a bit more work and there needs to be more communication regarding what is allowed on tables, if you don’t need DELETE then your DBA needs to know not to give permissions for it.

    Good DBA’s know that a secured DB with table access is just as secure as a DB with SP only access. Convincing less confident DBA’s of that is a much harder matter.

    • 0