[Building Sakai] [sakai2-tcc] Assignments Shows Wrong Submission For Student

[Steve Swinsburg]

You may not have got the gist of my earlier comments, but I was agreeing with you. 

I simplified my comments about why it makes sense in other use cases, I didn't feel that going into detail was necessary here though. And since XML isn't used properly nor is it necessary in this particular use case (i.e. Assignments or other parts of Sakai that are in reality, all just relational data), IMO it should be covered out into columns. However there are use cases where XML or other forms of serialised LOBs as data storage does make sense, which are out of scope of this particular discussion. 

Though saying what I said is a 'poisonous myth' isn't cool, since it aint no myth, there are some enormous applications doing exactly what I described, using XMLTYPE columns for their data storage. Sure, you may need to update your views if the XML format changes, but that is minor compared to the relational database way of adding more columns and more tables to keep your database normalised, and then code to join them all together.

S

On 07/03/2013, at 8:56 AM, David Adams <da1 at vt.edu> wrote:

> Steve Swinsburg wrote:
>> In Oracle, the XMLTYPE allows for direct querying of the XML within the
>> database, and many other powerful actions.
> 
> No matter how efficient, storing XML-as-XML introduces a lot more
> overhead than just storing the fields-as-fields. Offloading the XML
> parsing to the database would make some things more efficient, but it
> would partially just move CPU and memory load from the easier-to-scale
> app servers to the harder-to-scale database server. Unless we're
> working with XML for some specific purpose, then using XML at all is a
> huge waste of resources.
> 
>> Then you don't need to worry about database upgrades if you want to
>> add another column, the data just going into the XML and you work
>> with it.
> 
> This is not true, and it's a poisonous myth to propagate. Transitions
> are inevitable no matter what your data format. Yes, just adding a
> field to XML on the fly in your code is easy enough, but so is running
> ALTER TABLE ADD COLUMN. To use that new field, you have to build
> indexes and views in either situation. And if a data field needs to be
> broken out into another structure or converted to a different type,
> you still have to either update every record in the database with the
> new format, or put complicated and risky logic in your code to
> accomodate the multiple possible formats.
> 
> Not to mention that the schema of an existing database often serves as
> the best description of its structure, better than any outdated,
> mistake filled, human generated documentation. An RDBMS schema is
> provides free reflection to ORM tools and the like, not to mention
> human troubleshooters. With a schema-less format, you completely lose
> that benefit. If you force your XML to conform to DOCTYPEs or XML
> Schemas, suddenly you're back to writing DDL and dealing with schema
> upgrades, only with a much more complicated language that fewer people
> understand.
> 
>> You can create a dynamic view from that info for faster data access,
>> if required.
> 
> Again, this is extra work to get parity with storing data in
> relational form. And for the questionable benefit of being able to say
> your RDBMS supports XML natively. When we're using XML only as a
> serialization format in Sakai, all we've done is to add extra
> processing to both create the XML on app server and to parse it on the
> database server, creating a lot of extra work in the data layer, for
> administrators and DBAs, all for the sake of avoiding writing some
> boring DDL and checking the "XML" box.
> 
> -dave
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc