Re: The right database for the job?
- From: "Jim Kennedy" <kennedy-downwithspammersfamily@xxxxxxxxx>
- Date: Wed, 13 Jul 2005 06:25:39 -0700
<Chavoux@xxxxxxxxx> wrote in message
news:1121248313.965798.34500@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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
>
Bad idea. Bad design. You have WAY too many moving parts. You need to
find out WHY this current set up does not work and fix the underlying cause.
What you propose to do is too complex to work reliably. Once you find out
the root cause for your problem you can fix the problem. That might mean
changing databases, that might mean some sort of application optimizations.
(more likely, 90% of all optimization problems are application problems not
database problems) The "solution" almost sounds like some inexperienced
engineer is now enamored with some technology and needs to implement it to
expand their resume. Don't do it.
Jim
.
- Follow-Ups:
- Re: The right database for the job?
- From: Kenneth Downs
- Re: The right database for the job?
- References:
- The right database for the job?
- From: Chavoux
- The right database for the job?
- Prev by Date: Re: Break into the Computer Industry - Get Hired Now
- Next by Date: Re: The right database for the job?
- Previous by thread: The right database for the job?
- Next by thread: Re: The right database for the job?
- Index(es):
Relevant Pages
|
