[thesite] last 5 query

[Dean Mah]

jeff writes:

> what would you call a trigger that performs a cascading delete to
> maintain data integrity in child tables?  is this just trivial
> business logic or does it do the job (of maintaining relational
> integrity) at the closest point to the data?  does it make sense to
> have the programmer have to remember that he must delete child
> records whenever he performs a delete on the parent table (which
> could conceivably happen in more than one place in the application)?

I'd write a library routine.  Isolates the business logic and let's
all developers use common code.

> i can agree with constraints.  once the application is built, the
> constraints don't really play much of a role as the application code
> must be written to shield the user from the constraint errors
> anyway.

Right.  So to me, constraints don't really contain business logic.  At
least not business logic that exists elsewhere.

> if the programmer doesn't understand what's happening with the data
> then you have at least two problems on your hands.  first, they're
> in over their head - too little knowledge or experience for what
> they've been asked to do.  second, whoever is directing the project
> is doing a poor job of communicating the details of the project via
> database schemas, requirements documents, etc.

Ideally, everything is documented.  However, jump into a legacy system
with little documentation and try to figure out what is going on and
support it.  As an example, what kind of design documents do we have
for the evolt structure?  If I wanted to jump in to the backend
programming full time, what's the best way to learn the system as it
exists?

> now, if you're doing complex architecture changes with triggers like
> writing temp tables, adding/removing columns, changing datatypes,
> etc. then the problem isn't with triggers.  the problem is with the
> approach to the problems.  the solutions are causing more problems
> than they're solving.

Sure but this partially gets back to your question of where do you
draw the line.  In my current development environment, we've chosen to
draw the line at no triggers or stored procedures.  A couple of the
reasons are:

1) Separate business logic from presentation and database layers.
   Make it easier to change models.  Make it easier for developers to
   see the separation.

2) Do not rely on Oracle as a database.  In theory our product can use
   any database in the back without having to worry about converting
   triggers and stored procedures to the database's specific language
   and which features are supported.  For example, MySQL doesn't
   support triggers at this point.

> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : Whether the additional code sits in the application layer or
> : the database layer there is still the same potential for coding
> : errors.
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> don't get me wrong.  i completely agree with that.  i'm just saying
> that the fewer lines of code you have to write, the less likely you
> are to make an error.

Sounds like an argument for code re-use.  You can get the separation
without having to re-write the same routines over and over again.

> i think it'd be fair to say that if you're a programmer that's
> working with building dynamic web applications you better be solid
> with more than just one or two languages.  you better know the
> middleware language (asp, cf, php, etc.), you better know html, and
> you better know sql really well.  nothing earth-shaking there.
> that's just the facts of building a quality solution.  if you're not
> solid with these (and probably javascript as well) then you probably
> don't have any business being employed in that capacity.

We require people to know those things but we don't expect them to
know them at an expert level.  We hire junior as well as intermediate
/ senior developers because of the marketplace and available
resources.  We can't expect everyone to be able to jump into a
situation and know all of the required languages and tools.  One less
requirement makes it easier to fill positions.  We also separate a lot
of our work into teams.  We have Java gurus, Perl gurus,
user-interface people, database gods, QA teams, client handlers,
network specialists, etc.  We're getting away from the idea of the
'webmaster' where they need to know all of the languages, server
configuration, network layout, operating system tuning, etc.

> now we're saying the same thing.  i think the performance hit should
> occur when a new record is inserted into the database - not whenever
> a visitor to the site requests a page.

Sounds good.

Perhaps one thing that we should keep in mind as the deadline gets
closer, program for completeness now and refactor for performance and
other things later.  We don't want to miss a deadline by getting
caught up in issues along the way.

Dean