What are your best practices around creating flat file database structures in PHP? A lot of the more mature PHP flat file frameworks I see out there attempt to implement SQL-like query syntax, which is over the top for my purposes in most cases (I would just use a database at that point).

Are there any elegant tricks out there to get good performance and features with the small code overhead one would want by taking on this problem in the first place?

+6  A: 

One way to store flat-file content would be to save literal arrays to php files. For example:

$data = array();

if( $_POST ) {
  $data = $_POST;

  $content = "<?php\n";
  $content .= '$data=' . var_export($data, true) . "\n";
  $content .= "?>";

  save_to_file($filename, $content);

// echo form

That's true. serialize() can be pretty useful for that as well.

I think the trick to coming up with a viable system is finding some way to index the data nodes without killing yourself with complexity.

This is post #100!
Isaac Waller

That's true. serialize() can be pretty useful for that as well.

You could serialize, but this saves a step since you don't have to unserialize. Not sure if its actually better performance-wise.

I think the trick to coming up with a viable system is finding some way to index the data nodes without killing yourself with complexity.

Maybe have one central file that keeps track of all indexes? Like tags.txt which has a list of all post id's associated with each tags. May have to keep redundant data around to save time.

+6  A: 

Well, what is the nature of the flat databases. Are they large or small. Is it simple arrays with arrays in them? if its something simple say userprofiles built as such:

$user = array("name" => "dubayou", 
"age" => 20,
"websites" => array("dubayou.com","willwharton.com","codecream.com"),
"and_one" => "more");

and to save or update the db record for that user.

$dir = "../userdata/";  //make sure to put it bellow what the server can reach.

and to load the record for the user

function &get_user($name){
return unserialize(file_get_contents("../userdata/".$name));

but again this implementation will very on the application and nature of the database you need.

+17  A: 

You might consider SQLite. It's almost as simple as flat files, but you do get a SQL engine for querying. It works well with PHP too.


If you're going to use a flat file to persist data why not use XML to structure the data?

PHP has a built-in XML parser: http://uk.php.net/xml


If you want a human-readable result, you can also use this type of file :


This way, you have only one file, you can debug it (and manually fix) easily, you can add fields later (at the end of each line) and the PHP code is simple (for each line, split according to |).

However, the drawbacks is that you should parse the entire file to search something (if you have millions of entry, it's not fine) and you should handle the separator in data (for example if the nick is WaR|ordz).

+1  A: 

In my opinion, using a "Flat File Database" in the sense you're meaning (and the answer you've accepted) isn't neccesarily the best way to go about things. First of all, using serialize() and unserialize() can cause MAJOR headaches if someone gets in and edits the file (they can, in fact, put arbritrary code in your "database" to be run each time.

Personally, I'd say - why not look to the future? There have been so many times that I've had issues because I've been creating my own "proprietary" files, and the project has exploded to a point where it needs a database, and I'm thinking "you know, I wish I'd written this for a database to start with" - because the refatorinf of the code takes way too much time and effort.

From this I've learnt that future proofing my application so that when it gets bigger I don't have to go and spend days refactoring is the way to go forward. How do I do this?

SQLite. It works as a database, uses SQL, and is pretty easy to change over to mySQL (espescially if you're using abstracted classes for database manipulation like I do!)

In fact, espescially with the "accepted answer"'s method, it can drastically cut the memory usage of your app (you don't have to load all the "RECORDS" into PHP)


Here's the code we use for Lilina: http://lilina.googlecode.com/svn/trunk/lilina/inc/core/class-datahandler.php

It stores each entry as a separate file, which we found is efficient enough for use (no unneeded data is loaded and it's faster to save).

Ryan McCue

A low level object API ffdb is link text