Design:Index
From ssc.aspirationtech.org
Contents |
Database Design Overview
With SSC we're targeting a platform that can store a wide, and flexible set of data, and operate on it largely agnostically. For the prototype we're building a tool of operating on lists of items which are described by fields roughly analagous to the DOAP schema.
Key challenges
- Some fields are repeatable. (Software could have many authors, or many mailing lists)
- All fields should store locale info for future i18n.
- We want a system by which new fields can be added to the system, by a list maintainer
- Lists store potentially heterogeneous items, including other lists
- Notifications need to be able to operate on items, lists, and lists of lists
Solving the mixed list problem
If a list can contain any kind of item, then it suggests that items are a generic type, and that specific item types "inherit" from the generic item. To this end the item table is simple, containing only the core fields (id, name, description, type)
Solving the lists of lists problem
Lists contain items, but lists also contain other lists. This suggests that a list is a type of item, joined with many-to-many joining table.
As modeled in the database *any* item type can have sub-items, but it might be semantically meaningless for the front-end to convey this
Expandable, repeatable, and internationalized fields
The bulk of the data is stored in the "fields" table (perhaps better named "values"), which captures the:
- name of the field
- value of the field
- locale of the value
- id of the item containing this name, value, locale triple
Future iterations would want
- explicit field types that allow the storage of complex data types
- a separate field definition table rather then a simple string name
For these field:
- Fields can be multi-valued
- fields need to store at least a string value, and often will want to
store a link, a title, and a description. short term we need to enable "pretty links" probably using the wiki-style "link name|http://someurl.org"
- fields are sorted into views
- custom (user defined) fields, fields currently all live under the
Custom/More/Extra view/perspective. Custom fields are per list, and values for custom fields are per list per item.
- we want to capture the "who" information at the field level:
- who edited it, ("who is bringing the love") and the
- "what" information (what changed)
Field groups (aka profiles, views, or facets)
Fields are displayed and edited in groups of related fields. The SSC Requirement doc refers to these as views with examples being "Technology", "Community", and "Localization". Currently these groups, and their sub-fields are stored in the code, but are designed to be replaced by a field definitions table.
Watches and notifications
Watches and notifications are much simpler, more traditional data models. Watches store the item id to watch (and in the future conditional logic, about what types of actions), and a user id who wishes to be notified.
Notifications is simply a queue of notifications waiting to be delivered to a user informing them of one of their watches being triggered.
