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