Re: [GENERAL] Re: Is PostgreSQL ready for mission criticalapplications?

On Tue, 23 Nov 1999 marten(at)feki(dot)toppoint(dot)de wrote:

> [SNIP]
> We've written a PostgreSQL->Smalltalk/X wrapper, now we are developing
> a oo->rdmbs framework on top of it and we've noticed the following
> problems with PostgreSQL 6.5.1:

wow, people still use Smalltalk ? i had figured that most moved to
Objective-C or Java.

> a) Due to the database layouts we are in need of doing all these nice
> sql-statements like "group by" and "having" ... and as posted earlier
> in this group: they're limited in PostgreSQL.
>
> Now if you need these aggregations urgently you get many, many
> problems and you have to produce work-arounds ...

why wouldnt you have 'group by' functionality in the framework layer like
NeXT's Enterprise Objects Framework? isnt the whole point to eliminate (
or nearly eliminate ) the need to key in SQL ?

EOF gives you methods like -[NSArray computeAvgForKey:], -[NSArray
computeCountForKey:], -[NSArray computeMaxForKey:], -[NSArray
computeMinForKey:], and -[NSArray computeSumForKey:]. using, say, 2
methods, one can more than likely get the 'group by' functionality you're
talking about in an OO and RDBMS-independent way. for instance:

- (NSDecimalNumber *)amountBackOrdered
{
EOQualifier *backOrderedQualif =
[[EOKeyValueQualifier alloc] initWithKey:@"isBackOrdered"
operatorSelector:EOQualifierOperatorEqual
value:[NSNumber numberWithBool:YES]];
NSArray *backorders;

backorders =
[[self orders] filteredArrayUsingQualifier:backOrderedQualif];

return [backorders computeSumForKey:@"amount"];
}

( somewhat familiar syntax, eh ? :) )

lookie, no SQL! and, oh, btw, this works if your datastore is a flatfile,
postgresql, oracle, sybase, informix, or that gdbm-ish database.

> And this is one reason for all problems running around: as with
> all programming languages all these guys come with special SQL
> knowledge (e.g. I use these statements very much ...) and now
> you come to POstgreSQL and find out, that these statements are
> special.

again, isnt the point of OO frameworks on top of non-OO RDBMSs to
eliminate the need to learn 20 vendors' implementations of SQL by
providing an OO 'alternative' ( for lack of a better word ) ?

> [SNIP]
> b) We had problems with vacuumdb here and there. Some times it cored.
> We've deleted a 300 MB database under psql and the backend cored ...

the largest table i have is ~71m and growing somewhat quickly:
-rw------- 1 postgres postgres 71753728 Nov 24 02:06 logins
-rw------- 1 postgres postgres 71761920 Nov 24 02:10 logins

... and ive had absolutely no problems vacuuming it under 6.5.x.

> [SNIP]
> When considering the fact, that PostgreSQl is a free database it is
> worty. Some persons are developing the database and if I
> could have a wish: please, please fix all these limitations of
> "groub by" and "having" statements and get closer to the sql standard.

www.pgsql.com, make a donation. :)

> And to mention, how different the expectations are: some persons out
> there mentioned, that referential integrity would be a very urgent need
> for them - I've the totally different opinion about this:
>
> When doing procedural queries to the database, this need is ok. If you
> put a full oo->rdbms wrapper on top of this database and do your
> programming in some oo-languages this need vanishes - because referential
> integrity does so much in the background, that your object-model in
> your application simply becomes wrong - therefore I throw away
> referential integrity. It makes the administration for the databases
> also much more simplier.

:) funny you should mention this -- there was a LOT of talk on the
webobjects mailing list about this recently. EOF uses two methods to add
objects to both sides of a relationship ( for back pointers ). these
methods end up calling two other methods in your custom classes. the
discussion was how to add two OTHER methods to front for
-addObject:toBothSidesOfRelationshipWithKey: so one wouldnt have to keep
typing that method ( and getting carpal tunnel syndrome in the process ).

but anyway... throwing RI away isnt all that wise, however. every db with
2+ tables would most likely benefit from keeping the two in sync, be it in
your object model or whatnot. of course, if your RI is in your object
model and object model ONLY, this would most likely present problems for
applications that dont use your framework; there's nothing preventing them
from mucking up your foreign keys. as long as you order your
inserts/deletes/updates properly, one can safely keep RI in the rdbms and
the object model... it get a little tricky when there's a table that
refers back to itself, though.

> Just my opinion .. not to be misinterpreted. I encourage every work
> the people push into PostgreSQL because I want to have a free
> database.

you know, in all honesty, i could care less if the product was free. if
it works, and works well, then ill use it. so far, pgsql has worked
_VERY_ nicely -- so nicely, in fact, that i havent felt the need to move
off to Oracle for my internal dbs.

---
Howie <caffeine(at)toodarkpark(dot)org> URL: http://www.toodarkpark.org
"Tell a man that there are 400 billion stars and he'll believe you.
Tell him a bench has wet paint and he has to touch it."