We wanted a system that gave both website architecture and database design the freedom that networks have to connect (or relate) any two points.  Library indexes have always done this, and Hypertext was invented for this purpose, but getting computers to do it in an organized fashion, even in the age of Hypertext, has been a real learning process.  On the website front, this translates to something as practical as ensuring that a page or other content can be listed more than once in a website navigation hierarchy, regardless of the type of content entry it is listed under.  Presto has gone this far, but has not taken the next step of managing hypertext linking within documents or between instances of document text.  That must still be done manually within the context of the HTML content editor, using "anchors". 

On a related front, we have set a goal to have the CMS system really understand and work flexibly with keywords.  We wanted to give content managers the ability to associate keywords with any content they were managing, and to make it easy for the website to display and organize content with respect to the keywords.  We've acheived much of our goals here, and remaining work is discussed in the future section.

For the scale of data representation that our target website projects involved, and given the pace of hardware and software speed, we thought we'd drop some assumptions that the traditional relational database design paradigm usually pushes.  The key design decision lies in the choice of the structure or skeleton that information hangs off of.  This is the main control of how things can be ordered, linked, moved, and found. 

We have chosen what we categorize as more of a Set or Network Database approach, where any type of content (typically defined primarily by a record in a table) can be connected to any other content item (in the same or another table).  All linking is defined through a separate linking table.  Many spin-off benefits have occured as a result of this approach, mainly in simplifying the (drag and drop) creation, sorting, renaming, (multilingual) sorting, linking and deleting of items of whatever stripe. 

An additional simple and somewhat limited system for setting rules to restrict the placement of content types within each other has been provided too.  So the Presto approach starts with a kind of free-love database, where anything goes, and then enables system designers to place general restrictions on relationships that can be established between content types, or between a particular content item and the types of its underlying items.

This is in stark contrast to the traditional relational database approach, where relationships between two content items are controlled by dedicated field(s) within the two content items, or are controlled by a dedicated table for connections made between the respective content type tables.  The latter approach requires special code for managing each relationship, and makes constructing a navigation hierarchy that may contain a mixture of items very tricky. 

There are benefits to a traditional relational database approach, where large numbers of content items (over 50,000 say) are involved, so Presto has mechanisms for dealing content that is stored in this traditional paradigm.  Such items just can't show up in the website navigation or backend Explore pane - and we wouldn't want them to be there anyways.  They are handled in reports fashioned for Presto's report interface.

Finally, since websites usually call for a hierarchic approach to organizing content items, and call for privileged (membership) access, we also wanted to have this reflected in the security system for accessing content items.  We wanted logged-in viewers and content managers to be given access to private sections or subsections of a website.  This means engineering the system to be quick enough to know what a user can or cannot see or administer. 

This problem is accentuated with searching - every time a search is performed on a mixture of private and public content, we need to calculate which of the items a given user is allowed to see based on their hierarchic right to view (or not) the content items that matched the search.  We wanted our solution to work with organization that have 3,4,5 and even 12 levels deep in their hierarchy of content items, with tens of thousands of items to vet based on a particular user's view or management links to places in that hierarchy.  It was impractical to just recursively query the ancestor(s) of each content item in question as part of the search itself.  Special Presto user-group-rights calculating code was required to acheive this.