|
Re: Document Centric Design Issue [message #124851 is a reply to message #124586] |
Tue, 21 June 2005 16:32 |
andrew again
Messages: 2577 Registered: March 2000
|
Senior Member |
|
|
A common practice in applications like SAP and Oracle Apps. is to add a few general purpose "flex" fields of various data types to selected tables. You then populate a meta-data table to configure what lables, validations those columns will have on the UI. The normalized approach of adding additional rows to a child table to represent additional columns on a parent table can be really messy - especially when you try to reconstruct a logical view of the physical tables. It can be done using views, but if you want them to be updateable too then it's not so easy...
|
|
|
Re: Document Centric Design Issue [message #124856 is a reply to message #124586] |
Tue, 21 June 2005 18:09 |
William Robertson
Messages: 1643 Registered: August 2003 Location: London, UK
|
Senior Member |
|
|
I might be missing something but I don't see what allowing end users to make ad hoc additions to your data model has to do with a Document-centric design, if there is even such a thing.
I don't think there is any substitute for having a data model in which thoughtfully named columns have a clear purpose and well understood properties. It's easy enough to add, modify, rename and drop columns in Oracle, and plenty of modelling tools to keep track of it all. Having a client app that presents column UDF_42 as "VAT Registration Date" is never as good as the real thing.
The flexibility to make changes later without having to pay consultants to think about it may understandably seem to the client like something well worth putting on the wish list - just be careful what you promise.
|
|
|
|
Re: Document Centric Design Issue [message #125032 is a reply to message #124913] |
Wed, 22 June 2005 17:53 |
William Robertson
Messages: 1643 Registered: August 2003 Location: London, UK
|
Senior Member |
|
|
Quote: | I have a parser which shall pick up changes to the document when invoked.
|
I'm afraid I have no idea what that means. What is a document? How does it change? Why does that affect the relational data model?
How is dropping and recreating a table any better than altering an existing table? What about all your stored PL/SQL? Oh, of course - all the logic will be in the client app, right?
|
|
|