Working without stored procedures or triggers

Question

We have been working on a complex database and client interface for the last 18 months. We are regularly adding new functionnalities to this application, and it is now used by tens of users on a daily basis in all our offices, including sites and overseas. This is just to tell you it is a REAL application with a REAL database.

Until now, we still did not have to write any stored procedures, except on a temporary basis to solve minor issues between client versions and updated database model (where the old client version will not properly update the newly created field, until everybody installs the newest version).

In the same way, we still did not need any triggers. In fact, the only SPs and triggers are the system ones, or the ones added for replication purpose.

I have the strange feeling that SPs and Triggers are mainly used to compensate for database design defaults and/or attempts to bypass database design rules, when developers consider that database optimisation has to oppose database normalisation.

The problem is that these tools are time-consuming (for both development or maintenance). Each developer shall then be very carefull using them, keeping in mind that they are the most "expensive" items to maintain in a database.

Could we consider that having none or few stored procedures / triggers in a database is a good indication of its normalisation level and/or its code maintenance cost?

EDIT:

Some of you have supplied fair arguments for the use of both triggers and SPs. But I keep on thinking that most of the time these tools are used in an improper or excessive way. How many triggers are set to make some fancy updates between table fields, or to recalculate totals or other aggregated data? How many SPs are used to build temporary tables for reporting issues? These are 2 among many situations where developers use these tools, and I think this usually illustrate database design/normalisation flaws.

Some others admit that use of SPs and triggers should be strictly controled. I find it necessary too.

I must confess that I am trying to find some upholding arguments, where all these SQL geeks working on our other databases look down at us, telling their friends "You know what? they do not even use SPs and Triggers! Haha!"

Answer 1

Stored Procedures and Triggers are tools -- very specific tools for use within a database management system.

Triggers have a number of uses, from greatly simplifying the maintenance of history tables (where each row represents a past period in time for the primary table) to queueing requests for ETL to a data warehouse (depends on the specific RDBMS)

Stored procedures also have their place, whether they're invoked from the application or from SQL command line tools.

Inclusion of Stored Procedures or Triggers really has no bearing on the Normalization or "database design defaults". Their use in applications often relates directly to other requirements of the application, those of scalability, reliability, replication or other requirements that can be most effectively met by using these tools.

If you don't need 'em, don't use 'em. Do not, however, assume that the presence of triggers or stored procedures indicates poor design.