Skip to main content
added 7 characters in body
Source Link
candied_orange
  • 114.7k
  • 27
  • 222
  • 352

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace the DB later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this far enough and you can find yourself writing you own DB.

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this far enough and you can find yourself writing you own DB.

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace the DB later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this far enough and you can find yourself writing you own DB.

added 4 characters in body
Source Link
candied_orange
  • 114.7k
  • 27
  • 222
  • 352

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this to far enough and you can find yourself writing you own DB.

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this to far and you can find yourself writing you own DB.

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this far enough and you can find yourself writing you own DB.

Source Link
candied_orange
  • 114.7k
  • 27
  • 222
  • 352

Are your restful endpoints the only thing talking to the database?

If 100% of the events that trigger the database go through RESTful endpoints then you have a way to detect them. Otherwise you’ll miss events.

Some events are emergent in the DB. A RESTful event makes you delete a row in table A. That cascades to a delete in table B. If Table B has a trigger on delete it’s easy to miss that logic if you move to RESTful code.

But there are certainly applications that can be done completely free of database triggers.

The drawback of DB triggers is they move business logic into the DB making it harder to replace later. The advantage is they can minimize traffic over the DB connection.

But sure, you can definitely eliminate triggers. Just do so wisely. Push this to far and you can find yourself writing you own DB.