Merlin Moncure wrote:
Geoffrey wrote:
We are going live with a application in a few months that is a complete
rewrite of an existing application. We are moving from an existing
proprietary database to Postgresql. We are looking for some
insight/suggestions as to how folks test Postgresql in such a situation.
Shouldn't you run your tests *before* rewriting your application? :).
You don't have to answer that.
The logic has been proven. What we want to really test is loading and
the remote possibility that the compiler built code based on what we
wrote, rather then what we thought. :)
We're also trying to decide whether a single database with multiple
schemas or multiple databases are the best solution. We've done some
research on this through the archives, and the answer seems to depend on
the database/application design. Still, we welcome any generic ideas
on this issue as well.
I can help a little bit here. Yes, this decision will be heavily
influenced by application design. Let's assume you have to keep
multiple identical table sets (suppose you have multiple companies on
the same server for example). Here are some general stipulations:
<great feedback snipped>
Thanks muchly for your insights. Just the kind of info we're looking
for. Now if I could only find that mind reading compiler.
We lean towards multiple databases when thinking about the possible need
to bring down a single database without affecting the others. We do
require access to multiple datastores, but that is relatively easily
done with either schemas or databases with perl and C, which are our
tools of choice. These databases are pretty much identical in design,
simply for different 'parts' of the business.
Any further thoughts are, of course, still welcome.
--
Until later, Geoffrey
