On 02/02/11 18:05, phil walker wrote: > Agreed it is the database. I guess I was not clear. If your > archictecture has layers dbms/DAL/BAL/UI then you COULD if you wanted to > theoretically at least change one of these without largely impacting the > other layers. Therefore if you did not like the dbms licensing model or > the customer wanted into to run on another dbms then (provided you had > written) the dbms schema and had a DAL for that dbms then you could > switch the dbms. Admittedly a bit of work, if you have an already > application, but gives you the flexibility of what you want.
The problem is, where do you put the layers. That's my beef with relational, the layer is in COMPLETELY the wrong place. This means a large chunk of information, which *belongs* in the database layer, *has* to be put into the business layer. Even the wording of relational theory makes this clear - data is stored as attributes. Attributes of what? Without an object to belong to, an attribute is meaningless, but you can't store an object in an RDBMS. > > Symeon thinks this is old school, and it is not without challenges, but > it does allow you to break each of the components which WILL change > independently of the others. U2 disappears for the example, or prices > itself out of the market you are in, the business/industry changes some > logic, or the user wants to use and iphone or see their business data in > a hologram ;-) > :-) But I gather it's actually a lot easier to move between MV databases from independent vendors than it is to move between relational databases. And how the user wishes to view the data has nothing to do with the integrity of that data. If, in the *real* world, various items of data are physically locked together, MV allows you to lock them logically together in the database. Relational all too often forces you to separate them, and then you need loads of extra logic to ensure they don't accidentally become separated. In the real world, you don't get monopoles, or lone quarks. In a relational database, it's only too easy to get the equivalent by accident. Cheers, Wol _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
