Skip to content

Floating Schema Schema

June 12, 2011

This is the eighth article in my series on creating comprehensive automation.  Click here to jump to the first article.

The Floating Schema System

The Floating Schema is a way to store over-arching schema information for all your database data, which can be used from any source, and can be implemented against many different platform and operating system level services.


A minimal description to specify that a database instance exists.

We give it a name, and a type, which can be as simple as a string such as “mysql” or a reference to a database type specification, which gives more precise and readily usable data.

Finally we give an URL, which can just by the type and hostname, such as “mysql://prodmysqldb/”, but could also include user, password and other parameters to pass to the database as URL arguments.

This is a very minimal representation, and should be expanded upon to suit your needs.

Database Schemas

Comparable to a table, but nothing is stored in this.  It is just a description of a container for specifying a collection of fields.

As such, we specify a unique id, the database this schema is in, the name of schema, any text info about the schema, and then access information by specified group or evaluated by a script.

Schema Field

Schemas are collections of fields, and in a field we specify it’s schema, it’s type, an optional custom formatting script, an optional custom default value script, and access information by specified group or evaluated by a script.

Version information could also be added to all of these fields, but was not to keep them simpler.

Schema Field Type

Field types provide a way to generalize how to validate, format, restrict access to and provide default values for schema fields.

What All This Provides

As you can see, creating a comprehensive automation system requires wrapping everything, including where our data sources are, what kind they are, and specifying what is in them.

The benefits received from this highly structured system is that APIs can be generated for scripts to use for doing any sort of reading and writing operations to our databases, and we can allow or deny queries based on authentication and access or data validation failures.

Display and interactive systems can be written against this data, and they will all be updated accordingly if they use the data and scripts referenced in the specification.  This provides a framework to write any level of tool against, and thus is a basis for a comprehensive life-cycle system.

Final Overview

Remember This?

From the Walkthrough of an MSGR System post, we have the screen shot of the MSGR application.

Take some time to compare the schema we have just created for the MSGR data, the CMS data and now our Database Schema data.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: