Let me clarify a little.
This is a case when the information is already gathered in the core database of the application as part of the system that has been in production for a year.
Another group of developers have created another program that will be one of several consumers of the data, but they need the data validated and in a specific schema. They are not the customer, but one of several consumers of the same data.
Although the data originates as a single technical document that is transmitted from the client and re-constituted on the other side to be processed, the second group of developers are arguing they have primary ownership of that data so it should be split off.
Also they have designed a transmission system in WCF, that has not been tested in the field yet, and their database does not exist yet.
My argument is that an existing system that does the same thing, should be modified to match the schema they need, and the transmisison method should not matter as long as they have access to the data. Also, if the records are part of a logical document, I would argue that they should be stored in the same database as a matter of simple design architecture and is in my mind the most logical approach.
If all they need is to consume data that is already part of an existing design, why does it matter to the other group where they read the data from? Both applications have access to the same databases on the central side, and they are only consuming a small part of the data.
Main Topics
Browse All Topics
by: djjariesPosted on 2009-10-08 at 01:52:50ID: 25523221
I assume the data is closely related. Sending the data in two packets can provide problems since you introduce the possibility of partial dataloss.
Storing the data in two databases is irrelevant since you can write views that pulls the data from the different databases and combines it for the client. The only reason for doing it (in my opinion) is if you need access to part of the data very quickly and very often. This approach is mostly used when there are no funds for a full configured SQL-server. By making use of datacubes and restricting access to certain views, you can reach the same objectives.
Your DBA is correct to insist that the data is not duplicated. For performance, redundancy can be a good thing, but it should not be overdone.
Using WCF instead of web services is a technical descision and has nothing to do with the database itself. There are pro's and cons for each of them.
The main point here, as I see it, is WHY does the customer want a seperate database. I would suggest that a second database with the views and procedures to access the main database should be sufficient as well, but if they insist, you can create procedures to insert the data from the client and store the data in two different databases from within that procedure. With this approach, you can still maintain the single datapacket from the client-computers while complying with the customers specs.