Adding Context to Web Application Data

In a previous post we defined what we call a Content Database - that is, a traditional database with layers of context on the individual rows that are common across most web and mobile applications.

There are lots of reasons why a Content Database is a better tool than a traditional database for building applications. Features like content organization, roles and authorizations, content revisioning and workflows, and content variants are all common requirements for modern applications that don't come with a traditional database, and developers are left with developing these features themselves in most cases.

This post is the first in a series detailing how these features can be added to a traditional database to make building web and mobile applications easier and faster to build. webCOMAND also implements these features in its open sourced API. Sign up today for free to see a fully-featured content database in action.

A Simple Example: Products

Many web applications will involve an e-commerce solution, where items for sale are organized and presented as products. Products in their simplest form contain a title, description, and price, but will often have color/size variations or other specialized fields depending on the type of item being sold.

Modeling the concept of a product in a traditional RDBMS, like MySQL or MariaDB, is straightforward, and the table might look something like this:

This simple Products table has all of the columns it needs to hold information about the product, including an Auto-Increment column to assign each post a unique ID. To fetch products below a certain price from this table we can do a very simple query like this:

SELECT Title FROM Products WHERE Price<100

This is, of course, an extremely simple example. Were this a real-world implementation, there would be several other requirements around the management of products in the system, including:

• Handling a broader range of products that have different fields, such as books or appliances
• Organizing products as the catalog grows, or as products are gradually phased out and discontinued
• Tracking who last edited products and when
• Authorizing users to access and modify only certain fields
• Viewing the state of the product catalog, or associated orders, at a particular point in time in the past
• Ensuring that products have been reviewed by all stakeholders and approved to go live
• Supporting multiple languages for product descriptions, multiple currencies for prices, or even product descriptions or pricing based on the profile of the application user.

While all of these considerations can ultimately be addressed by a combination of RDBMS features and application logic, none of these are available out of the box without considerable developer effort. A content database should close many of these gaps to enable applications to simplify the business logic used in communicating with the data layer and streamline the schema and application development process as a whole.

Implementing a Content Database

In the following series we will step through what we did in webCOMAND to implement content database features on an underlying traditional database. Links will appear as the series is written.

1. Abstracting Repository Content
2. Implementing Inheritance and Relationships
3. Introducing Content Workflow
4. Adding Organizational Structure
5. Introducing User Attribution
6. Implementing Role-Based Access Control
7. Revisioning and Content History
8. Point-in-Time Querying without Backups
9. Adding Content Variants
10. Adding Content Variants with Fallback

Cover Photo by _HealthyMond . on Unsplash