What exactly are your very best practices around creating flat file database structures in PHP? Many of the more aged PHP flat file frameworks I see available make an effort to implement SQL-like query syntax, that is outrageous for my reasons generally (I'd only use a database at that time).

What are the elegant methods available to obtain good performance featuring using the small code overhead you might want by dealing with this issue to begin with?

You may consider SQLite. It's almost as easy as flat files, but you will obtain a SQL engine for querying. It utilizes PHP too.

Well, what's the character from the flat databases. Could they be small or large. Could it be simple arrays with arrays inside them? if it is something simple say userprofiles built as a result:

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

and also to save or update the db record for your user.

$dir = "../userdata/";  //make sure to put it bellow what the server can reach.
file_put_contents($dir.$user['name'],serialize($user));

and also to load the record for that user

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

however this implementation will very around the application and character from the database you'll need.

One method to store flat-file content is always to save literal arrays to php files. For instance:

$data = array();

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

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

  save_to_file($filename, $content);
}

// echo form

For me, utilizing a "Flat File Database" meaning you are meaning (and also the answer you've recognized) is not neccesarily the easiest method to start things. To begin with, using serialize() and unserialize() may cause MAJOR head aches if a person will get in and edits the file (they are able to, actually, put arbritrary code inside your "database" to become run every time.

Personally, I'd say - why don't you turn to the near future? There has been a lot of occasions that I have had issues because I have been creating my very own "proprietary" files, and also the project has skyrocketed to some extent where it requires a database, and I am thinking "you realize, If only I'd written this for any database to begin withInch - since the refatorinf from the code takes a significant amount of effort and time.

Out of this I have learnt that future proofing my application to ensure that if this will get bigger I do not have to go and spend days refactoring is what you want forward. How do you do that?

SQLite. It really works like a database, uses SQL, and it is pretty simple to change to mySQL (espescially if you are using abstracted classes for database manipulation like I actually do!)

Actually, espescially using the "recognized answer"'s method, it may drastically cut the memory use of your application (it's not necessary to load all of the "RECORDS" into PHP)

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

It stores each entry like a separate file, which we found is efficient enough to be used (no needless information is loaded and it is faster in order to save).

One framework I am thinking about could be for any blogging service. Since nearly any possible look at data you'd want could be sorted by date, I believed relating to this structure:

One directory per content node: ./content/YYYYMMDDHHMMSS/

Subdirectories of every node including
/tags
/authors
/comments

and easy text files within the node directory for pre- and publish-made content and so on.

This could allow an easy PHP glob() call (and most likely a turnaround of the end result array) to question on nearly anything inside the content structure:

glob("content/*/tags/funny")

would return pathways including all articles labeled "funny".

That's true. serialize() could be pretty helpful for your too.

I believe the secret to approaching having a viable product is finding a way to index the information nodes without killing yourself with complexity.