I'm not part of the decision team on this, but here's my personal opinion anyway, FWIW.
I believe large efficiencies in developer velocity could be gained if OAE assumed a relational db. Going that way could *in theory* pave the way for future tools and facilities such as an ORM, a self-generating internal API, native data integrity enforcement at every level of the system, straightforward cascade deletes, and simplified output of data into other contexts (these services could be provided by existing Java tools or be built in-house as needed). Since all of these features assume a relational back-end, I see a move to relational as an important first step in the drive to simplify the OAE codebase overall. Frankly, I think we're paying a pretty huge price for not using a relational schema to begin with. Most of the data in our systems is highly relational, and relational data opens the door for tons of tools and capabilities we can't get with a non-rel system. IOTW, the decision is not only about current technical requirements - it's also about future tools and services that could come along for the ride. Just my .02. __________________________ Scot Hacker Senior Software Developer @ CalCentral Educational Technology Services, UC Berkeley [email protected] (510) 292-5586 __________________________ _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
