Flat-File versus Database Manipulation

[kratsg]

So, I've been trying to think up all the different ways in which one would be a better route to go than the other when creating some sort of a flexible Administrative Panel (you can think of it as like a generic panel that could attach itself to any site and help with management of files/users/data, protection of pages, and etc...).

 

When I talk about Flat-File, I mean that any information such as storing Admin Panel log-in information (encrypted of course with Sha1, MD5, and a salt-hash method) and anything specific to the site such as home page, pages to update (for any reason), templates to save, database information (to pull database information for users or whatnot) is stored in files on the server (most likely above the root directory so it is not accessible via public; if not possible to place above root directory, then have information saved in .ht____ files, where the "_____" signifies any name, such as .htusers because these files are [by default] not accessible through the browser).

 

With Database, the same information as mentioned above, but stored in a database using MySQL rather than in files.

 

Basically, I've been looking and comparing these two methods, their pros and cons...

 

Flat-Files have the main ability to be widely usable [as most servers with a BASIC php configuration will have file-manipulation "powers"], as well as a pretty fast time in accessing the data. Some of the downfalls are that if anyone gets your FTP access, they can 'kind of' destroy all the information, rather than access it (as it would be encrypted via salt-hash).

 

Databases are pretty sleek in data management and manipulation, and really helps with the organization of a website. It may not be as fast as it would be using flat-files, but does boost up security (if properly encrypted) as just because someone accesses your FTP doesn't mean they would have access to your databases (unless the passwords are the same). A downfall, for example, would be that a server would actually have to have databases in order for you to even use this, and any errors that popup can potentially reveal information harmful to your site (if you're not equipped with a good error handler).

 

Any thoughts, comments, things to add/change? This isn't really a project for any one thing in particular but I'm looking at seeing how well I can make a truly generic AdminPanel (that literally runs itself).

[Accurax]

Fine in principle .... but when you begin to talk about high traffic sites those extra database requests become much more of a problem.

[trq]

There is a flat file database engine (sqlite) built into php since version 5.0.0. If you need to do any type of searching / indexing a database is always going to win IMO.

[kratsg]

There is a flat file database engine (sqlite) built into php since version 5.0.0. If you need to do any type of searching / indexing a database is always going to win IMO.

 

See, that's what I've been thinking about, all those specific examples. It's obvious that a database is much more advanced and capable of things like searching a website for anything.

 

But, the one thing I wanna make sure is not confusing is the separation. Take a site who already uses databases for everything, from storing user information to indexing and pulling page information. Perhaps for some reason, they want a flat-file Admin Panel, the users registered through Admin Panel would be stored in flat files. So there's just so many variables to think of. Perhaps in the future, I want to include a feature to index/search any website via the Admin Panel, which means the most efficient way would be to use databases (which would be where flat-file loses the fight).

[kratsg]

Ok, so the next issue here is... security!

 

Flat File: because it would use .ht___ files and most likely be located above the root, you cannot access the files publicly. As long as the code is logical and covers up any holes, there's almost no way to "hack" into the files it stores information in? (other than actually getting the FTP info). If it has an error, it would show the site paths, which can be fixed by using a proper error handler.

 

Databases: SQL injection can be prevented (most) using mysql_real_escape_string() as well as taking proper security precautions, making sure global variables are covered, there's proper logic, etc... However, if one hacks into the database, that pretty much kills everything. If it has an error, it would show harmful information, but can be fixed by using a proper error handler.

 

I can't see a FATAL security flaw that can't be prevented with either of these methods? Any ideas?