Why another SQL schema?

Many database schema designs are not normalized to best facilitate general-purpose querying and to minimize redesign when extending the database structure.

Creating a highly normalized schema is not a simple task since complicated views and procedures must be designed to make the database usable.

Why CRUD free?

Schemata that implement the Create Read Update and Delete pattern for record access and management often lose correct information or any history of past changes. With a NoCRUD implementation, changes are made by adding new records instead of editing/over-writing previous information.

Why Stored Procedures for inserts?

An extremely simple insert may need to:

• Check for a previously assigned unique id
• Check for duplicates
• Retrieve and use data from more than one other table

Save client application programming steps while accessing the database; this schema is designed to act like all data already exists. So instead of doing an INSERT, a Get Procedure will return the ID field of the data to be found/inserted. If the data does not exist, then it is inserted before the ID field for the record is returned.

Why use Views

The hardest thing to do in highly normalized databases is remembering how to correctly use all of a schema's complicated table relationships and business rules. A view is an object that looks like an ordinary table to standard queries. Views also give the accessing programs a relatively static interface to the database, allowing more freedom to make significant schema changes without triggering changes in client applications.