SQL: Old Soldiers Never Die

Structured Query Language (SQL) has been a phenomenally useful language for the relational database era. But I see that era coming to a close.

One of the primary flaws is SQL allows for database Alters, Drops, Updates and Deletes. When diskspace was expensive this made perfect sense, but with the unlimited disk resources we have today a greater principle holds true: NO SCHEMA OR DATA SHOULD BE ALTERED, DROPPED, UPDATED OR DELETED.

A second flaw is the lack of interactive modification of the schema in real time. Changes still blow most applications all to hell.

A third flaw is supertype/subtype hierarchies. Such things should not be hard coded into a design.

That being the case SQL has four unnecessary statements just waiting to be abused. We need a better language. In fact, we need a better database architecture.

A new language would provide no means for updates or deletes. I created the first Releases of this language I called “Structured Thinking Language” (STL).

STL has the following commands:

  1. CREATE – affordance concept (creates entities)
  2. DIRECT – affordance context (relates entities)
  3. POSIT – affordance method (entity output)
  4. OBJECT – affordance pragma (entity input)
  5. NEGATE – affordance cosmos (entity security)
  6. INTUIT – affordance chronos (entity manipulation)

As you can see there are no means to delete data.

Each entity (noun) has only one “attribute” in the relational ERD sense and each entity value is unique.

Each relationship between entities is called an direction with a subject, verb and object.

What we are actually dealing with is a database that has data states. Data being no longer affected by Alters and Deletes are instead affected by change of state without physical alteration or deletion.

After looking at STL recently I realized I had created a command language for an existing database architecture: The Associative Model of Data by Simon Williams.

The Book on the Model and a free copy of the Enterprise Edition software is available here.

An old release of STL can be found here.

Icons: Systema

I finally put together a broad range of icons for the System Elements. Remember Causus (Why), Ductus (Who), Modus (How), Datus (What), Eventus (When), Locus (Where):

Design: Attacking Convention

It’s wrong. The way we think about managing files in applications is wrong. And it is wrong for one reason. It lacks conceptual abstraction, simplicity and consistency.

“Wait!” you may say, “the icons are the same in all the applications! We’ve got the sheet of paper for ‘New’, the opening folder for ‘Open’ and the diskette for ‘Save’. We’ve even got a cute magnifying glass for ‘Search’.”

Frak the magnifying glass!

That’s part of the problem. The “New”, “Open” and “Save” icons should be sacrificed on the alter and replaced. New is relatively acceptable, but when we open it is not file we open but a folder. When we save we are not saving to a diskette. And we shouldn’t even be using the term “File” for anything. We are managing “Email”, “Documents”, “Worksheets”, “Presentations”, “Databases”, “Calendars”, “Projects”, “Drawings”, “Contacts” and “Browsers” people! If our applications are single function so should be what we are editing.

When you “Open” you could be uploading or downloading into your computer’s memory. When you “Save” a document, you could be uploading it to a hard drive on the web or downloading it to your hard drive; it could be burning it to a CD-ROM or good heavens even writing to a diskette. I’m not going to draw little hard drives. I’m going to abstract the concepts completely.

I always hated the clipboard metaphor. I just decided to call it a “content block”. You either delete it from your document, copy it from your document, update your document with it or select it in your document.

This is not my final version in the least. But I wanted to put some food for thought on the tabula rasa.

Icons: SQL DDL and DML

I’ve been playing around with some icon ideas for SQL Data Definition Language (DDL) and SQL Data Manipulation Language (DML) for some time. Perhaps they will give you some ideas.

First are the Basic DML Commands:

Now let’s apply them to Tables:

Tables need Primary Keys:

They may also need Unique Indexes:

We may have to play with the Columns:

Then we should have Views:

And in special cases Triggers:

We should also define Users:

Now we have all the DDL.

Let’s look at the DML:

Having manipulated our data we should either Commit or Rollback:

And that is about how far I’ve come.