Re: How much of data constraints on database is enough?

Hi Miho

Good question. The blah answer is that is depends on the application.

Of course, this isn't very satisfactory. Another answer may be that
keeping logic close to the data is not very fashionable. Ad-hoc ORMs
that lack solid theoretical foundations are in fashion. These have
the effect of fooling application developers into thinking they need
to know nothing about the relational model. They get to write great
swathes of OO code where simple declarative query statements would
suffice.

This is still an unsatisfactory answer. My answer would be that
whilst I think that in principle declarative programming and keeping
logic close to the data is to be preferred, SQL and procedural PL/SQL
type languages do the relational model a disservice. Nothing against
the pg one in particular, it's the procedural aspect that is
troublesome. It would be nice to have more expressive power whilst
staying within the relational/logical paradigm.

On Jan 15, 2008, at 10:07 PM, Miho Ishikura wrote:

> Hi people!
>
> I have a question that I'm always not clear about.
>
> Let's say there is an application that talks to PostgreSQL database.
> And you want to add constraints around it. Constraints contains
> validations, business logic, data integrity.
>
> I have worked on the applications that was very database driven
> before. We had a lot of constraints like foreign keys, unique keys,
> check constraints, triggers, functions... etc. It was very rich and
> quite fun. I would love to do that again if I have a chance. I
> understand that it can be done and SQL on Rails is no joke (!).
>
> Being said that, you also have choice to do the same in your
> application as well. Why do you want to have them in 2 places? Maybe
> some constraints are appropriate to be done in application, some
> should be on database. But where do you draw the line? Might as well
> do them all in application!?
>
> What do you think?
>
>
> Miho
>