Re: PG rules! (RULES being the word ;->) - Mailing list pgsql-general

> But watch out the discussion "Application Design and PostgreSQL"
> these Days in the list. I thought your way. Thought it is pretty cool
> to have all logic inside the database, but it seems it isnt!

Don't listen to them!  Every case is different.

> How do you do your error checking?
> You won't be vendor independent!

I throw myself to the mercy of Postgres!

> How do you check if your php sends a '1' instead of 'true' to the
> database. I think you can only catch this error with a midllerware.
> switching the databse is impossible.

I am married to Postgres!

> im just thinking about the same problem at this time and i am
> convinced by others to put the business logic in the middleware and
> just use SQL to store simple tables.

I am familiar with that argument.  It's a good point in some
instances, but it isn't gospel by any means.

The question is, how much portability do you really need?  In my case,
I know that I'm working on a domain name registry.  Even being
optimistic, let's say we get 100k domains registered.  A 100k row
table is well within PG's capabilities on appropriate hardware/OS
(1.2mhz AMD, 2gig RAM, FreeBSD should do it).  At the same time, I
know that an Oracle license is completely out of our budget for the
foreseeable future, so me worrying about being able to run my
application on Oracle is like me worrying about which color Rolls
Royce looks best.

So, can you really say that this particular application needs to be
portable at all?

What kind of application really needs to be portable?  If you think
it's going to be small (in terms of data set size and transaction
volume), then go with PG and commit to it.  If you think it's going to
be big, then why not get the budget and do it on Oracle or DB2 to
begin with?

I'm not saying that portability has no value, but you should always do
a cost/benefit analysis of portability (and all the other major design
requirements), and try to make some intelligent assumptions about the
future, to see whether it's worth investing the substantial extra time
and money in writing middleware.  Perhaps some kind of accounting
database at a rapidly growing company would be a good candidate for a
highly portable design, because you can't afford Oracle right now, but
you are pretty sure you'll need the extra power later.

I've decided that my paricular application doesn't need portability,
so I'm going to make full use of all the great features of PG to
ensure data integrity and the highest possible stability.  If our
marketing projections are wrong, and we get 1mil domains registered in
the first month, then certainly we will need to make some changes, but
we will also have a lot more budget power.  We can always get by by
upgrading hardware and other tweaks.

Now of course if I were a Java consultant, getting paid $100/hour to
write Java middleware, I might feel differently about all this...