←back to thread

570 points davidgu | 1 comments | | HN request time: 0.238s | source
Show context
polote ◴[] No.44525307[source]
Rls and triggers dont scale either
replies(2): >>44525677 #>>44525805 #
shivasaxena ◴[] No.44525677[source]
Yeah, I'm going to remove triggers in next deploy of a POS system since they are adding 10-50ms to each insert.

Becomes a problem if you are inserting 40 items to order_items table.

replies(5): >>44525741 #>>44526565 #>>44526644 #>>44526757 #>>44526964 #
GuinansEyebrows ◴[] No.44525741[source]
that, and keeping your business logic in the database makes everything more opaque!
replies(1): >>44526749 #
lelanthran ◴[] No.44526749[source]
> that, and keeping your business logic in the database makes everything more opaque!

Opaque to who? If there's a piece of business logic that says "After this table's record is updated, you MUST update this other table", what advantages are there to putting that logic in the application?

When (not if) some other application updates that record you are going to have a broken database.

Some things are business constraints, and as such they should be moved into the database if at all possible. The application should never enforce constraints such as "either this column or that column is NULL, but at least one must be NULL and both must never be NULL at the same time".

Your database enforces constraints; what advantages are there to code the enforcement into every application that touches the database over simply coding the constraints into the database?

replies(2): >>44526911 #>>44532956 #
1. GuinansEyebrows ◴[] No.44532956[source]
you make good points; i'm overcorrecting from past trigger abuses :)