Re: What databases have taught me

Marshall,

> It depends. If we imagine the same query existing in two places
> in the code, and imagine what could make us want to change it
> in the future, do we imagine that we'd necessarily change *both*
> together or might we just want to change one?

I'm wondering how this argument goes if we replace "two" by "ten" or "one hundred".

What is it that caused us to need the same query to appear at two different places - and how likely is it that the same forces will require that we have the same query in three places, then maybe four, etc. If we do have four or more instances of the same query, do we more easily imagine wanting to change all of them?

Your question "how little code can there be such that we still call it a coherent abstraction" is interesting when you ask it about the original example:

  select name from employees where today()-birthday > X and city Y

Wouldn't you say that the calculation "today() - birthday" calls for abstraction ? It really means "age", so the code should say "age". The means of abstraction doesn't have to be a method - a view would work in the above.

I would want to ask, too, what the condition "older than X and living in Y" means. It seems likely that it stands for something more abstract: say, "the employee is eligible for a particular healtcare plan".

If that were the case, the answer to your original question would be "Change Both", because when the rules for eligibility changed, the change would need to apply to all places in the code where we compute a list of employees based on eligibility for that plan.

How would you introduce that kind of abstraction using SQL?

Laurent Received on Wed Jul 05 2006 - 10:45:04 CEST