Difference between revisions of "DatabaseRedesign"
Line 29: | Line 29: | ||
* [[DatabaseSchemaV3]] |
* [[DatabaseSchemaV3]] |
||
* [[TableStructureDiscussion]] |
* [[TableStructureDiscussion]] |
||
+ | * [[RaleighDesignNotes]] |
||
[[Category:Developers]] |
[[Category:Developers]] |
Latest revision as of 16:03, 8 March 2013
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.
Requirements
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.
Implementation
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.