Skip to content

DB Implementation

Craig Zheng edited this page Apr 27, 2011 · 1 revision

Background

Symphony 2's database implementation was less than ideal. The naming convention was confusing, the schema wasn't optimized. Symphony 3 should address these issues at the outset.

The following was proposed during a Symphony working group meeting on 26 April 2011 (transcript). Draft 1 in progress...

Proposal

Symphony 3's database implementation should yield significant performance improvements over Symphony 2. It should use fewer queries, and queries should execute faster.

...

Scope

For version 3, we're continuing to focus on MySQL. We'll be looking at the overall structure of the database, what's stored there vs in flat files, how things are stored, etc.

Ideas

  1. InnoDB for core tables, investigate cascade
  2. Relationships should be handled by the database (refer to Relationships discussion)
  3. Transactions should be used where appropriate
  4. Investigate impact of ORDER BY, FORCE INDEX on performance
  5. OT: Delegate subscriptions, ditch the compiled index, determine dynamically from drivers
  6. OT: Delegate order, allow a execute_first and/or execute_last flag
  7. Consider the indexing/caching of entries in blobs, or variations thereof
Clone this wiki locally