Re: Database design pattern question
- From: jerry gitomer <jgitomer@xxxxxxxxxxx>
- Date: Tue, 19 Jul 2005 21:05:56 GMT
Andrew McLean wrote:
In article <SRNCe.4869$Kz3.3058@trndny04>, jerry gitomer <jgitomer@xxxxxxxxxxx> writesOne principle that you should always follow is to keep the design as simple
Andrew McLean wrote:
In article <1121628648.995189.91800@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, --CELKO-- <jcelko212@xxxxxxxxxxxxx> writesDon't worry about understanding it for now. (If you choose to do more research on data bases you will understand it.) Just accept the fact that Joe knows what he is talking about and unless you have a good reason to do otherwise it is best to take his advice.
This design fallacy is called attribute splitting. You are putting things that belong to one entity split over multiple tables.
I'm afraid I don't understand this point.
I'll put that another way, I didn't understand how that related to my situation.
as possible (while still doing the job). One key reason is to minimize the cost and other impacts of maintenance over the life of the application. IBM ran some studies in the early 1960s which revealed that doubling complexity increased system life cycle cost by a factor of 4!
[ snip ]
I'm finding the discussion useful, thanks to everyone who has contributed. The one issue no one has commented on so far is actually my major motivation for the suggestion I made. That is the problem that I really need to be able to have multiple copies of the databases being updated in parallel and to have the ability to synchronise them later.
Whoa, what you describe is mutually exclusive. Either you will do local processing and synchronize periodically or you will run a truly parallel database operation.
If you only need to synchronize once every day or so this will work. If you go this route consider updating a central database as the first step and then downloading the central database to each of your local databases. A more attractive alternative is to consolidate your transaction logs and then download the consolidated transaction log and run it against each of the local databases. This is preferable because it will only be necessary to download transaction activity for a day or two at a time rather than downloading the entire database.I see two approaches to this:
1. Maintain a transaction log and "replay" the transaction log for each copy of the database into the other databases..
2. My idea of deliberately storing the data that is being updated in the form of events, such that synchronisation simply becomes a matter of forming the union of the multiple copies of the event table.
If the RDBMS you are using permits cross system joins and supports UNIONS
this too will work. The first step would be to create an updated central
base by doing a cross system join UNION operation that would build an updated event table. The second step would consist of downloading the event table to each of your local databases and then dropping the old event table and doing a create table as select from table.
My personal preference is for the first approach. I think it is safer to download transactions and run them against an existing database table.
HTH Jerry .
- References:
- Database design pattern question
- From: Andrew McLean
- Re: Database design pattern question
- From: --CELKO--
- Re: Database design pattern question
- From: Andrew McLean
- Re: Database design pattern question
- From: jerry gitomer
- Re: Database design pattern question
- From: Andrew McLean
- Database design pattern question
- Prev by Date: Re: LIMIT in a subselect, but without using subselects
- Next by Date: YellowFin Web Based Reporting
- Previous by thread: Re: Database design pattern question
- Next by thread: Extracting data from DBF files
- Index(es):
Relevant Pages
|