Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Triggers can blossom into a performance problem. About the same time that happens they've also become a maintenance nightmare. You can't figure out what's happening <strong>and</strong> (bonus!) the application behaves erratically with "spurious" data problems. [Really, they're trigger issues.]</p> <p>No end-user touches SQL directly. They use application programs. Application programs contain business logic in a much smarter and more maintainable way than triggers. Put the application logic in application programs. Put data in the database.</p> <p>Unless you and your "users" don't share a common language, you can explain the constraint violations to them. The alternative -- not explaining -- turns a simple database into a problem because it conflates the data and the application code into an unmaintainable quagmire.</p> <p>"How do I get absolute assurance that everyone's using the data model correctly?"</p> <p>Two (and a half) techniques.</p> <ol> <li><p>Make sure the model is <strong>right</strong>: it matches the real-world problem domain. No hacks or workaround or shortcuts that can only be sorted out through complex hand-waving explanations, stored procedures and triggers.</p></li> <li><p>Help define the business model layer of the applications. The layer of application code that everyone shares and reuses.</p> <p>a. Also, be sure that the model layer meets people's needs. If the model layer has the right methods and collections, there's less incentive to bypass it to get direct access to the underlying data. Generally, if the model is right, this isn't a profound concern.</p></li> </ol> <p>Triggers are an train-wreck waiting to happen. Constraints aren't.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload