> As programmers, we naturally want to throw things into databases for
> three reasons. First, it's easy to get data in. Second, it's easy to get
> relevant data out. And third, it's "cool". We don't want to work with
> flat files, now do we? ; )
Kiddin', eh? :) Actually, the third reason seems to dominate the younger
developers' minds. People often tend to keep everything in poor DBMS until
it begins to kick back. And this has impact on the customers. Does your
system use a database? No, why should it? You mean you'll keep our dearly
beloved banner ads as flat files? Yes, this is where they belong. Sorry,
we'll seek for someone more advanced. Good luck.
Of course, hardware vendors jump up of joy :) Maybe I don't get it, but
IMHO there's no reason to put into DB something that can't be indexed and
used in where clause.
> It would *not* allow the
> database to do joins, it would grab entire tables, then try to do the
> joins
> itself, in Perl.
Umh.... Yeah.... Well.... To keep compatibility with other Open Source
Databases and ESR/RMS, you know :)
> (Incidentally, we've toyed around with developping a query-caching
> system that would sit betwen PostgreSQL and our DB libraries.
Sounds amazing, but requires some research, I guess. However, in many
cases one would be more than happy with cahced connections. Of course,
cahced query results can be naturally added to that, but just connections
are OK to start with. Security....
--
contaminated fish and microchips
huge supertankers on Arabian trips
oily propaganda from the leaders' lips
all about the future
there's people over here, people over there
everybody's looking for a little more air
crossing all the borders just to take their share
planning for the future
Rainbow, Difficult to Cure
