A radical new shift in data storage; Rumblestorage
Friday, April 1, 2011 at 9:00AM Last night I had an epiphany. I was working with one of those old, cruddy databases, and it got me thinking. Why isn't there a better solution? Why am I doomed to use legacy systems such as MySQL and MongoDB for the rest of eternity? So, I began researching alternatives. And when I couldn't find any, I chose to write my own.
I am proud to announce Rumblestorage. From now on, every project of mine will be using Rumblestorage as its data storage medium. I hope that you too can see the light and understand that, frankly, databases just don't cut it any more.
Rumblestorage utilises the native capabilities of your language and stores everything in a flat text file; a simple and elegant solution. It brings your data into memory at class instantiation and saves it on destruction. It has a beautifully usable API. It's clear that in this 21st century world, databases are just far too restrictive. Your storage engine should be built specifically for your programming language; it should be fast, easy to use and above all flexible.
Best of all, Rumblestorage is free and open source, available on GitHub. I'm already in talks with the CodeIgniter Reactor team as to integrate Rumblestorage as a replacement for the old and tired database class.
php, programming, ruby
Reader Comments (2)
What the hell do you smoke?! I'm sorry, but you sir, are a tool...
Database systems such as MySQL aren't "legacy" and they certainly aren't "restrictive". If you are limited in what you can do with something like MySQL then I think you will find that it is actually you that is restricted, and you are doing it wrong.
Please enlighten me as to how your "new storage medium" tackles such problems as:
1. Entity relationship, normalisation/atomicity and maintaining referential integrity as is implemented by engines such as Innodb
2. Indexing, cardinality and providing database level protection against repetition
3. Replication
4. Transactions
5. Logging
6. Clustering, failover, redundancy
7. Searching. How the hell does your shitty little engine find a row from millions? Are you maintaining any indexes?
I'm sure there are many, many more. I am in no way a skilled database developer/admin, however I do know that the current way of storing information in a DBMS is both flexible and powerful for billions of users worldwide.
Are you telling me that developers using "Rumblestorage" must rely on application logic to protect against common pre-DBMS problems as mentioned above? Oh please. This is the whole point of a database, to abstract off and handle these restrictions, rather than having to manage it in the application layer.
Why reinvent the wheel? What are you going to come up with next? An alternative to object orientation?
Good sir, while I read and appreciate your zeal for such matters I implore you to read the date on this post. I then, with almost equal importance, ask that you step back and think, for a brief moment, whether or not any sane developer would actually believe this pile of crap?