Opinion: File Based Applications to replace Database Systems

OpenEdit's Joel Halse believes that file based applications and not the database driven systems are the next evolution for information management. The below article is written by Joel Halse and explains his reasons for why he has reached this conclusion.

Lets say you need to organize 2000 people on a football field. A relational database would create 2000 little boxes and make everyone stay in their little box. If someone needed to move around, they would first need to inform the administrator so that the administrator doesn't lose track of everyone. A file based system on the other hand would hand out a cell phone to everyone and tell them to have fun. If someone needs you, we'll give you a call. Just make sure you don't lose your cell phone. Beyond that, have a great day.

A relational database was a good system. It was also created in a time where searching a million files took more than milliseconds. It was a product of limitations. It wasn't necessarily the ideal solution, but it was a good solution given the tools at hand. Those limitations are gone. Those limitations are in the past. New technology and mind boggling search capabilities have opened the door for new options that weren't available 20 years ago.

File based applications are the next evolution for information management. Especially for the web.

Why? Because it's easier understand. It's not that you aren't smart enough to understand a database. It's that you don't have to understand a database. Especially when you already understand how to use a file based system.

Who is YOU?! That's the key to my argument. YOU is everyone!

To run a database driven web application you'll need a DBA. If you don't know what that stands for you aren't alone. It stands for Database Administrator. But if you want to work with a file based system, all you need is you. If you can find files on your computer, you can find the files within the your file based web application.

First let me highlight two historical examples of emerging technologies that changed the face of data management, and then let me draw the parallel to the emergence of file-based systems. Notice that each example required a few iterations to achieve true success but the magnitude of their impact is enormous.

The first example is Windows. Windows crushed DOS as the operating system of choice because it focused on people. All of a sudden the common user could touch and feel files. Move them around. Drag and drop. Everything became accessible because you could wander around and find what you were looking for. This concept has revolutionized the way people interact with their digital information. Just imagine if you started your computer this morning and had to interact with your files using a command prompt. ACK!! The idea is unimaginable for the vast majority of the computer market place. The average computer user knows nothing about developing software and writing code. Keep in mind that the average person publishing to the web is the same average person who owns a personal compueter. Most people publishing to the web aren't programmers.

My next example is Google. Google dominates the search engine marketplace because it focused on people. Google is like a person. A very reliable and friendly person whose greets everyone with the same comforting approach that 50% of the WHOLE WORLD trusts to find what they are looking for online. That's a heck of a lot of people and a heck of a lot of trust. Google gained our trust with a very simple approach. If Google were a person, Google would probably look like a friendly librarian that instantly makes you feel relaxed and less stupid. And we all hate feeling stupid. Google would say something like, "Hi. Just type what you are looking for in this magic little box and I'll go find it. Don't worry about being wrong either because I'll only take 0.22 seconds to find 34 000 000 options. I'll sort these options for you too so what you are looking for will probably be one of the first ten options on the list. If I don't find the right thing then just ask me again. I'll keep looking. How much? *laughs quietly* Oh my dear boy, you don't have to pay me a red cent. I'll be here 24 hours a day, 7 days a week. If you need something, just ask." Incredible!

What has this got to do with file based web applications? Well, let me explain how you do a simple change within a file based system vs a relational database.

Let's say we want to make a change to a file. For this example the file is a web page. Specifically, the web page is http://demo.openedit.org/folder/file.html

Now let's make a change to this file or web page.

File Based:

This is the location of the computer: http://demo.openedit.org

This is the location of the file on the computer: /folder/file.html

Now go ahead and change the file. Use any tool you like. OpenEdit's file manager is one option. FTP is another option. You can also use the operating system running on the host machine to locate and change the file. That's it! Go make a change to that file. No caveats. It's that easy.

Relational Database:

Umm.. I don't know how to make changes to files within a database. I know how they work but if I want to figure out how to actually use one, I would have to start reading books about databases. But I don't want to learn about databases. I want to create web applications. I've been developing web applications for over 4 years and I know pretty much nothing about managing a database.

I can create something that works like a database. I can organize over 100 000 files into an organized, fully indexed structure of files that can be searched much the same as Google. But I can't run a database. Why should I? The goal isn't to have a cool database. The goal is to have organized and easily accessible information. I want to put all my files somewhere, have them organized, and then be able access them when I need them. No rules. Just let me find my files and give me access to them when I need them.

A relational database can't give you direct access to your files. Notice I didn't say won't. A relational database would give you direct access if it could. But it can't.

Here's why.

In a relational database everything needs to be in a specific spot and giving you direct access to the file can have dire consequences. A database doesn't understand that file.html is in a folder called /folder on a computer called http://demo.openedit.org. Instead, a database understands the location of file.html in relation to everything else around it. Recall the football field example? For the database to work you have to ask the database to go get the file for you. In fact, if you went and deleted the file without telling the database you risk corrupting the entire thing. If box 1276 on our football field had the wrong person in it then you probably can't be sure that the rest of your boxes were correct either. If file.html isn't where it's supposed to be than the database often gets confused and can't find anything. When a database gets confused it can lose track of everything. And that's bad. Really bad. So bad they created a term for it. Corrupt. Being corrupt is so bad that every relational database requires an administrator function that acts as the gate keeper to ensure this very bad thing never happens.

It is this requirement that causes so much grief for database management. Despite the enormous amount of effort that industry has invested into making these administrator functions easy to work with, they are a REQUIREMENT. A relational database requires an administrator function and can never allow you direct access to the file system. It's part of system's architecture.

Until now this was the best way to manage large amounts of information. New technology keeps changing the rules and we are in the middle of another big change.

If you want to organize over a million files you no longer need a database. You can keep your files unlocked. You can say goodbye to database administrators. You can regain control.

This new reality is probably terrifying for the database industry but it's proving to be nothing short of earth shattering for me!

You Must Be Joking

At least you qualified this as an "opinion", but this was the most hilarious article I've read in some time - and coming from a source that should know better.

Be bold and keep it online so we can all write back in 2010 and laugh even harder. I find it almost stammeringly confounding that the same quarter in which Sun buys MySQL for one billion dollars, Joel makes the stunning observation that databases are dying and that the database industry should be fearful of the future.

And why does he believe all of this? Besides a hogwash analogy of historical perspectives (which are highly skewed to his own recollection and worldview), the central reason for his thoughts here are that, well, it's just dog-gone easier for him to deal with flat files.

How wonderful. Hey, it's not exactly like databases are super tough these days. But he's completely rogue if he thinks that flat file data storage has anywhere near the power and scalability of flat file storage. In fact, there's not a single major web application out there that uses flat file storage. And any minor ones that do will be upgrading to a database server as soon as they get the one thing they crave: users.

Still, for a Monday morning, I can't think of a more encouraging article. It shows that we web developers are going to be in business for a long time to come. There are still, quite obviously, a huge gamut of "should-ers" out there - those who believe things should just work the way they believe - regardless of history, regardless of raw data and facts, and regardless of their understanding. And no, I'm not speaking of Apple fanboys, but they run a close second here.

confessions of a user..

When I read 'coming from a source that should know better' I thought, uh oh. I should have introduced myself

I'm not a programmer. I am a user. Before entering into this mine field I should have made that clear.

With that in mind, consider the above dialogue. While you immediately dismiss the importance of ease-of-use, you also point out that what all web app owners crave is users. CMS systems are no different. They crave users. And most CMS users aren't developers. They are regular people. People who work in marketing departments. People who need to publish information to the web daily because it's their life line to new sales leads. I would like to see programmers spending more time focussing on the needs of the too often forgotten end user. When discussing technologies for mass consumption, ease of use is very relevant.

I admire Apple (I'm also glad I don't work for Steve Jobs but that's another topic..) They understood the importance of ease of use. Their sexy UIs have earned my respect. It has also earned them a big pile of cash. Ease of use is the point I was making with my chosen examples. And yes, they are highly skewed to my recollection of events as a user.

Looking back, I see that I gave the impression that I'm a developer. That was not my intent. I'm not a developer. I'm a user. As such, I enjoy the file based system because the files I need to access everyday aren't locked away in a relational database.

btw - thanks for taking the time to comment. I've been thinking about it all day

 

Joel Halse

www.openedit.com

n/a

Complex Rollups

How do you handle complex rollups, aggregation, files (as opposed to text) and other data manipulations in your system? I guess I fail to see how this can work when your situation goes beyond simple static pages.

Can you explain further?

Funny

Is it funny that this URL from the story....

http://demo.openedit.org/folder/file.html

...returns "File Not Found"?

hmm.. thanks Deane

Less funny and more embarassing. Difficult to be taken seriously with an oversight like this. We encourage people to use our online demo to experiment with OpenEdit which requires us to rebuild our demo daily (if not more often) to keep it running smoothly. I failed to check the file I'm using as an example into CVS which is why it wasn't there this morning. It's fixed now.

Joel Halse

www.openedit.com

n/a