The right database for the job?
- From: Chavoux@xxxxxxxxx
- Date: 13 Jul 2005 02:51:53 -0700
Hi
I need some advice from people with experience in a number of different
databases.
Background: Application is running MsSQL Server on central database:
Main server and failover server. DB server-side application access MS
SQL server and handles all transactions from remote stations (many
updates per second during day-time). It can't handle this load and
fails (even with back-up!). We plan to replace this setup with a kind
of "thick client" or distributed Database, but I'm not sure what (RDMS)
would be the best tool for the job.
The idea is to have different zones, with up to 150 local database
servers each having only a section of the main database (all data
applicable only to that zone). Instead of updating and querying the
main Database all the time, updates of the main Database occur only
when requested by the main database or at night (when little or no
transactions are triggered) and local queries are handled locally. In
theory this should make the load on the main database much lighter and
give a stabler system with less network congestion.We would prefer not
having to continue using MS SQL Server for cost reasons. We also
consider running the zone database servers on embedded Java (JVM)
(aJile chip with harddrive attached).
Databases systems I'm thinking about are the following:
PostgreSQL
MaxDB
Cache'
Firebird
If we use the aJile zone DB servers, we might need something like
HSQLDB, Berkeley DB JE or Derby (Cloudscape)? Else port one of the Open
Source databases to Java?
Requirements of the (R)DMS:
1. Possibility to automatically update the distributed zone DB servers
with the apllicable portions of the database.
2. Possibility to keep the data "in sync". If certain changes happen at
the zone server level (triggers?), the main database needs to be
updated immediately and also update the other zone databases for which
the change might matter.
3. The possibility to store log files locally at the zone database
server and update the main DB server only periodically.
4. If the main DB is queried (happens less frequently), it should
update itself automatically by getting the latest/newest version of the
queried tables from the different zone DB servers.
5. From the application's point of view all of this should be
transparent. It should just need to query or update the database and
not know whether it is the central database or one of the zone
databasis that it talks to.
6. Obviously standard DB functions like referential integrity,
cascading updates/removes etc. should be part of the DMS.
7. Speed, data consistency, accuracy and reliability (no falling down
under heavy loads) are the main requirements.
I have too little experience to make an informed choice and because
this is a large project, we cannot afford to choose the wrong DMS only
to find out later that it is unable to do what it must.We would prefer,
to use Open Source Software, but something with a reasonable price like
Cache' is also an option.We could stay with Microsoft, but paying for
MS Sql server on all zone DB servers will be too expensive and I'm not
sure if the Desktop Edition would be able to do everything we need.
Any advice appreciated. No flame wars about best DB please!
Chavoux Luyt
.
- Follow-Ups:
- Re: The right database for the job?
- From: Paul
- Re: The right database for the job?
- From: John Currier
- Re: The right database for the job?
- From: Jim Kennedy
- Re: The right database for the job?
- Prev by Date: Re: Limit the number of left join
- Next by Date: Re: Break into the Computer Industry - Get Hired Now
- Previous by thread: Joining and pagination
- Next by thread: Re: The right database for the job?
- Index(es):
Relevant Pages
|
