Simple "Database" Class (Flat-File storage of data)
Moderator: General Moderators
Simple "Database" Class (Flat-File storage of data)
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!
- Attachments
-
- ar_editor.jpg (98.7 KiB) Viewed 2136 times
- daedalus__
- DevNet Resident
- Posts: 1925
- Joined: Thu Feb 09, 2006 4:52 pm
Re: Simple "Database" Class (Flat-File storage of data)
there are a lot of classes like this out. and its kind of hard for me to see what you mean through all those words but not everyone here is like that so expect better answers later in the day.
but if you are thinking about it like its a database table then test would be the table and the keys and values would be the columns and data so you kind of already have what you are asking for.
why not just use an ini file?
http://us2.php.net/manual/en/function.p ... i-file.php
but if you are thinking about it like its a database table then test would be the table and the keys and values would be the columns and data so you kind of already have what you are asking for.
why not just use an ini file?
http://us2.php.net/manual/en/function.p ... i-file.php
Re: Simple "Database" Class (Flat-File storage of data)
Not sure what you're aiming at. If it's only for small tables, then I doubt performance is a concern at all, and regardless - I would assume SQLite would be more performant. Not to mention, it offers much more flexibility and integrity than you could possibly accomplish without some extensive expertise with database architecture.
Remember that SQLite is an extension - written in C - it's very hard for me to fathom that you could outperform it by manipulating data in PHP. My advice - stick to what is a very mature and robust solution (SQLite) unless you have some time to kill.
Remember that SQLite is an extension - written in C - it's very hard for me to fathom that you could outperform it by manipulating data in PHP. My advice - stick to what is a very mature and robust solution (SQLite) unless you have some time to kill.
Re: Simple "Database" Class (Flat-File storage of data)
Pytrin, you're generally right. SQL is still new to me, though, and it takes me time to make sure I am parsing the results correctly. The idea behind this is that it is very simple, and very fast to implement, especially when I am tracking nothing more than a few basic settings. If all I am tracking is 5 variables, but I want them to not be stored as just lines in the file, isn't SQLite rather overkill?
Now, that INI file thing? That looks like what I've been looking for! daedalus, thank you! It may not serve exactly the same purpose, but it does several things I've needed in the past, and have had to work out other ways to do.
Now, that INI file thing? That looks like what I've been looking for! daedalus, thank you! It may not serve exactly the same purpose, but it does several things I've needed in the past, and have had to work out other ways to do.
Re: Simple "Database" Class (Flat-File storage of data)
For that you don't need tables, a simple hash array would do (serialize / unserialize). I use that myself on occasion. When you start playing with tables and columns, it's time to go the SQL route in my opinion. Especially if you need something like search.
Re: Simple "Database" Class (Flat-File storage of data)
I suppose I could write a wrapper around SQLite, and make my interface use that. Do you know, off hand, a good resource for finding what SQL commands will give me information about the structure of a database? I have not had much luck finding information on the SQLite spec (the book is always checked out at the university library). I would need to be able to get a list of the tables, how many columns are in a table, and so on. Basically, I want a minimal and more portable simple SQLite table editor. I know there is http://phpsqliteadmin.sourceforge.net/ but I've never been too happy with it, and it still leaves me having to compose SQL statements for even simple queries, which is something I want to avoid. (SQL is still not a "second language" to me yet.)
Re: Simple "Database" Class (Flat-File storage of data)
I find the MySQL documentation to be an excellent reference on SQL (though a small portion of it is MySQL specific).
You have SHOW TABLES for getting a list of the tables in a database -
http://dev.mysql.com/doc/refman/5.0/en/show-tables.html
And DESCRIBE for the table's structure -
http://dev.mysql.com/doc/refman/5.0/en/describe.html
You have SHOW TABLES for getting a list of the tables in a database -
http://dev.mysql.com/doc/refman/5.0/en/show-tables.html
And DESCRIBE for the table's structure -
http://dev.mysql.com/doc/refman/5.0/en/describe.html
Re: Simple "Database" Class (Flat-File storage of data)
Awesome! I knew there was a reason I loved these forums! I need to not be away so long this time.
Thanks again!
Re: Simple "Database" Class (Flat-File storage of data)
It seems your example is based around storing configuration data. I would always prefer configuration data to be stored in a flat file like an .ini file rather then a database. I like the .ini file format. The reason it is helpful to store configuration data on the filesystem is not only speed, but its usually more obvious, and less prone to bugs. In Magento users were having problems because it stores config data in the database. There was something with negative values getting reset to 0 or 0s getting replaced with 1s, based on how you did you SQL dump & load process. Because Magento was so brittle the simple change of that config option caused every application to throw an uncaught exception with a really obscure error message that was impossible to track down. Oops.
Re: Simple "Database" Class (Flat-File storage of data)
Haha, I love software like that. (not really!)
And yes, this is part of the reason I am working on this. An INI seems like a great way to go, but the one thing that I still have as an issue there is having a through-the-browser way to edit the data easily. (This will be often used in my very simple CMS). That's why I created the little editor in the screenshot above. It makes it so very easy to create the registry at first, and with the simple hooks that are part of the access class, it is very easy to update values. I can even implement it almost brainlessly as part of the CMS. It also means that if I want to create a new value for the user to be able to modify, I just upload the one script, select the .ar file, add the value, and the abstraction layer makes it show up in the CMS. Delete the editor, and I'm done.
And yes, this is part of the reason I am working on this. An INI seems like a great way to go, but the one thing that I still have as an issue there is having a through-the-browser way to edit the data easily. (This will be often used in my very simple CMS). That's why I created the little editor in the screenshot above. It makes it so very easy to create the registry at first, and with the simple hooks that are part of the access class, it is very easy to update values. I can even implement it almost brainlessly as part of the CMS. It also means that if I want to create a new value for the user to be able to modify, I just upload the one script, select the .ar file, add the value, and the abstraction layer makes it show up in the CMS. Delete the editor, and I'm done.