Re^2: persisting Moose objects and schema evolution

Many thanks for your post that I will study in more detail later.

Just one thing to make my idea clear:

I do not intend to story any information twice. Every attribute would EITHER be mapped to a database-column OR would be part of an XML / or YAML data-structure in a CLOB.

So there would be no duplication beteen the data stored in fields of their own the the data stored in the CLOB.

And if I was to use XML for the CLOB (or the approriate XML-datatype) I could even access this data using some XPath-expression from any other environment/language (at least you can in Oracle).

Just for clarification...

Comment on Re^2: persisting Moose objects and schema evolution

Replies are listed 'Best First'.
Re^3: persisting Moose objects and schema evolution by ELISHEVA (Prior) on Apr 08, 2009 at 15:52 UTC
Thanks for the clarification... Usually when people selectively map some attributes to DB fields and some to CLOBs it is because the CLOBs contain data that is either (a) only of interest to a specific application (e.g. display attributes used by web app X) or (b) because the data represents some complex chunk of data that just doesn't normalize in any meaningful way (photographs, certain kinds of geographic data and network maps come to mind). Of course, the Oracle XMLType changes this reasoning a bit since, at least according to the documentation, you should be able to navigate the embedded XML data using SQL. However, I've never used this feature and there are a lot of niggling little questions I would want to know more about before I relied on it: How well integrated is the XML data into Oracle's transaction management, stored procedures, triggers, etc? Is SQL the only DB-like feature or does Oracle view this as a set of DB tables, just stored in a funny place? What happens if the XML data needs to reference data stored in normal tables via foreign key? Will the normal foreign key integrity checks take place? Conversely, if normal fielded DB data is updated, are updates cascaded into the XML data? Can both select and update queries use views that include joins that span regular tables and tables embedded in XML data? To what extent is the client locked into Oracle already (due to other business applications)? Do they want the option to change to another DB back end at some point in the future? If so, what other databases support such close DB/XML integration? Are those databases that the client would consider scaling up to? It would be unfortunate for a client to get locked into a DB solely because a mission critical application decided to be creative with features that only Oracle provides. Best of luck with your choices, and have a happy Easter/Pesach/Springtime weekend, beth	[reply]

Replies are listed 'Best First'.

Re^3: persisting Moose objects and schema evolution
by ELISHEVA (Prior) on Apr 08, 2009 at 15:52 UTC

Thanks for the clarification...

Usually when people selectively map some attributes to DB fields and some to CLOBs it is because the CLOBs contain data that is either (a) only of interest to a specific application (e.g. display attributes used by web app X) or (b) because the data represents some complex chunk of data that just doesn't normalize in any meaningful way (photographs, certain kinds of geographic data and network maps come to mind).

Of course, the Oracle XMLType changes this reasoning a bit since, at least according to the documentation, you should be able to navigate the embedded XML data using SQL. However, I've never used this feature and there are a lot of niggling little questions I would want to know more about before I relied on it:

How well integrated is the XML data into Oracle's transaction management, stored procedures, triggers, etc? Is SQL the only DB-like feature or does Oracle view this as a set of DB tables, just stored in a funny place?
What happens if the XML data needs to reference data stored in normal tables via foreign key? Will the normal foreign key integrity checks take place? Conversely, if normal fielded DB data is updated, are updates cascaded into the XML data? Can both select and update queries use views that include joins that span regular tables and tables embedded in XML data?
To what extent is the client locked into Oracle already (due to other business applications)? Do they want the option to change to another DB back end at some point in the future? If so, what other databases support such close DB/XML integration? Are those databases that the client would consider scaling up to? It would be unfortunate for a client to get locked into a DB solely because a mission critical application decided to be creative with features that only Oracle provides.

Best of luck with your choices, and have a happy Easter/Pesach/Springtime weekend, beth

[reply]