What are everyone’s opinions on normalizing a database out across multiple databases. For instance, say you had a database that allowed different clients to sell products. You had abstracted the concept of an order, order item, etc., but each client wants a different field added here or there.
You could add the fields to the specific table, creating a wide table that had values in it that not all clients utilized, or you could create a tall table that listed a column-name and value so as to make it appear that you are appending on columns to a specific object (for instance, wanting a Home phone number on the order table when there only exists a Work phone number).
Or you could normalize out to a client specific database that has a table called CustomOrder that keeps the original order id from the generic database and then adds the columns necessary to accomodate the client.
Has anybody used a solution like this? I know referential integrity would be hard to control across databases, but it does keep the original generic database small and lean while allowing clients to customize to their hearts contents.
What are everyone’s thoughts on this type of design?
I’ve worked in that environment and it became a real nightmare. We had a main application which was managed by one team and others managed the client specific customizations. THe problem then became that multiple clients got customization that were simliar but not exactly the same (although they could have been if anyone every looked at what other clients are doing before they design their own). Since the team that did the main application that applied to everybody was paid for by the company and not the individual clients, we never had enough people there to generalize specific client needs so that other could use them when the need arose and so created 20 different custom solutions to do the same thing. Further, as client deadlines tended to be sooner than the general team could handle (there were only two of them out of 100 developers), even when something would make a good generization, it was handled in the client database to meet the dealines. Soon there was such a big mess that refactoring the database to fix design flaws became impossible because there were so many different possible applications that could be affected, no one dared to try to refactor. Then what would happen would be a fix was put into place for a specific problem but the old method would stay there and each client would choose a differnt way to implement even the things in the main application database. Organizational changes to try to add a design team to this mess after it was created then caused an almost comlete halt the work that could be accomplished because none of the new work met the new design standards without a complete rewrite of the existing site (that of course the clients didn’t want to pay for as the current version worked just fine to them). Stay very far away from this model!