From WeBWorK_wiki
Revision as of 16:03, 8 March 2013 by Djun Kim (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This article has been retained as a historical document. It is not up-to-date and the formatting may be lacking. Use the information herein with caution.

After WeBWorK 2.0 is released, we're going to be dropping support for GDBM databases and going to a pure-SQL system. This gives us a chance to redesign the database to better suit our current needs and provide for easy future expansion.


Moved to a separate DatabaseRequirements topic.

A related topic is what's going to happen with the ProblemLibraryArchitecture. The issue of how to reference a problem in a new-style problem library may affect what we do here in the database.


Right now, I like Class::DBI:

Class::DBI provides a convenient abstraction layer to a database.

It not only provides a simple database to object mapping layer, but can be used to implement several higher order database functions (triggers, referential integrity, cascading delete etc.), at the application level, rather than at the database.

This is particularly useful when using a database which doesn't support these (such as MySQL), or when you would like your code to be portable across multiple databases which might implement these things in different ways.

In short, Class::DBI aims to make it simple to introduce 'best practice' when dealing with data stored in a relational database.

Table structure