Simple "Database" Class (Flat-File storage of data)
Posted: Thu Dec 24, 2009 9:14 am
Hi All,
Years ago, I came across a little library called "FFDB" which was basically a class that allowed you to store information in a file, and provided functions for accessing the information. Now-a-days, there's SQLite which does much the same thing, but is infinitely faster and more powerful. Sometimes, though, it's still more than I need. Sometimes, I want something incredibly simple, just a file with a table of data, and a way to search it and make basic edits. The class would make it incredibly simple to use: $results = $myflatfile->search('blah'); for example.
Yesterday, I wrote a "registry" based on the idea of the Windows registry. It uses a serialized array, and stores key-value combinations. It makes it an incredibly simple way to store, say, configuration data for an "under construction" page. Along with the file containing the class, I wrote an interface (regedit) that lets me edit all the *.ar (array registry) files in the same folder. I've attached a screen shot so you can see what I mean.
I want to expand, though, to be able to create multiple columns. This presents all sorts of interesting design challenges, now. As such, I bring the question to you all.
What ideas do you have? Keep in mind, one of the benefits of using a serialized array, is that it eliminates a lot of problems with special characters. For example, I could use a CSV, but then I would have to be careful to escape commas, etc.
Currently, my idea is to use three levels of arrays.
There is an array with one element, where the key indicates how many "columns" are available in the "table". This value is an array with each element being keyed and containing an array with the specified number of elements. This has a few benefits I can see:
1. It's fast. Straight dump to and from memory. Since this is for relatively small amounts of data (maybe a hundred items in a big list) it's very efficient.
2. Flexible. I can expand the approach to handle several "tables" per registry.
What are your thoughts on this? Is there a better way to achieve the same thing? How large of a file do you think this will handle before SQLite overtakes it in speed and efficiency? Thank you all!
Years ago, I came across a little library called "FFDB" which was basically a class that allowed you to store information in a file, and provided functions for accessing the information. Now-a-days, there's SQLite which does much the same thing, but is infinitely faster and more powerful. Sometimes, though, it's still more than I need. Sometimes, I want something incredibly simple, just a file with a table of data, and a way to search it and make basic edits. The class would make it incredibly simple to use: $results = $myflatfile->search('blah'); for example.
Yesterday, I wrote a "registry" based on the idea of the Windows registry. It uses a serialized array, and stores key-value combinations. It makes it an incredibly simple way to store, say, configuration data for an "under construction" page. Along with the file containing the class, I wrote an interface (regedit) that lets me edit all the *.ar (array registry) files in the same folder. I've attached a screen shot so you can see what I mean.
I want to expand, though, to be able to create multiple columns. This presents all sorts of interesting design challenges, now. As such, I bring the question to you all.
What ideas do you have? Keep in mind, one of the benefits of using a serialized array, is that it eliminates a lot of problems with special characters. For example, I could use a CSV, but then I would have to be careful to escape commas, etc.
Currently, my idea is to use three levels of arrays.
There is an array with one element, where the key indicates how many "columns" are available in the "table". This value is an array with each element being keyed and containing an array with the specified number of elements. This has a few benefits I can see:
1. It's fast. Straight dump to and from memory. Since this is for relatively small amounts of data (maybe a hundred items in a big list) it's very efficient.
2. Flexible. I can expand the approach to handle several "tables" per registry.
What are your thoughts on this? Is there a better way to achieve the same thing? How large of a file do you think this will handle before SQLite overtakes it in speed and efficiency? Thank you all!