PHP Emulated SQL Filesystem? Say what now?

http://www.phpclasses.org/package/9...storing-files-in-SQL-database.html#view_files

Okay, so this is a "notable" PHP-package, which is meant to emulate a filesystem in SQL - and I'm just wondering... why?

The information on the link is not too good, so I was wondering if anyone could shed some light on this - won't a "file system" emulated in SQL be worse than just manipulating actual files on the harddrive? Especially if the harddrive in question is an SSD-drive?

What would be the benefits of this (apart from maybe security through well-formed PDO-queries, and of course, if you have limited amount of actual file-space, but no limit on SQL-size) - but for storing lots of files, and large files at that, in SQL?

Granted, I haven't really looked at the class itself, just read the info-page and such, but... why?

 

Here is more info on it:

http://practicalproductivity.com/sqlefs/

 

Well... "more info" is kind of a misnomer. I fail to see the benefit. There is no real info about WHY one should use this. I also don't understand why this is in any way better than just using SQL normally (I'm guessing it has to do with specific indexing, table construction and perhaps search-improvements)?

My point is still: why not just use the file-system? Why introduce another point of failure to access files?

 

you might need relations and can't have a proper database server. there are hosting companies that don't allow nothing. not even SQlite. So it's a way to use relations. Still, this is from the top of my head. haven't seen the class itself. But I can image there should be a use case somewhere

 

While I get that relations might be needed, I still don't understand for the need for storing the _actual files_ in the database. That seems like a HUGE overhead. When you could just as well store them on the filesystem, and just keep a reference in the database?

 

Sure. But what if you have a db on a separate machine and no way to share through nfs a filesystem? I don't know but there must be an application for it

 

My guess, from looking at the involved codebase and methodology? It's some fat bloated halfwit mouth-breathing dumbass asshat bullshit sleazed togther by some drooling twerp who has zero business writing code... as evidenced by storing some sort of connection data in the session, storing the write log in the session with no obvious purging (that's got to be fun after ~20 or so visits, that wonderful slow climb in execution time as that crap has to be loaded) and using dynamic table names.

But to be fair, I say the same thing about Bootstrap and jQuery so YMMV...

 

What does a database on a separate machine have to do with anything? The database can be located on the space-station for what I care - you just reference the file on whatever server/system the file is actually on? You can have a separate web-, db- and fileserver for all I care. And if you for some reason don't have the opportunity to share files directly from the filesystem, you need to a) get a new server, b) get a server properly set up og c) both of the previous choices.

I don't see ANY use for this, whatsoever. And, it being a "featured" class on the site I linked to just goes to show that they usually have no clue what they're doing over there...

 

It's PHP Classes.. "The site that used to be good"

My defense for it is a bit for legacy reasons. I remember a time where it was in fact faster to have things in filesystem. I used to be a Perl developer and we used a technique where we stored entire data structures in files on a shared volume behind load balancers. Then we had spiders that burned those files (structures called storables) because it was a lot faster than having the footprint of the db connections. We just restore it and use it directly..
I guess in current days it doesn't make any sense and you're right PoPSiCLe

 

Yeah... I was sort of thinking someone perhaps had some good arguments for _why_ using this would be useful for anything, really. Unless you're running your server off a derelict old server with a limited bus, say a first-gen SCSI, or old IDE 4200 RPM drives with no cache, then _maybe_ this would be faster (given that you were running your db-server off something else entirely, of course) - but today, with SSD drives, modern filesystems, and the general access-structure on most decent OSes... yeah.

 

Actually, I was just mulling it over and I can think of a legitimate usage scenario... and it's related to something I've been playing with.

Some hosts lock out readfile, fread, fopen, get_file_contents and so forth for security reasons -- it locks out the ability for PHP to do things like read the contents of a security related file and echo it out. If you need filesystem type behavior and those filesystem commands are blocked. It's not unusual to come across shared hosts where something like this is in the php.ini

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,fopen,readfile,file_get_contents,file_put_contents,file

In which case having something that behaves like a filesystem for storing things like avatars or so forth may in fact be needed.

Though at that point I'd say just get a better host...

Even though I still say that 99% of such nonsense wouldn't be needed if they just made it so include and require cannot open files that don't have a .php extension, and fopen, readfile, etc were blocked from opening files ending in .php -- do you have ANY idea how many simple common PHP exploits would fall flat on their face if that were done?

That's what I'm playing with right now -- since I've got a "one index to rule them all" whitelist .htaccess in place, (anything that's not a static file like jpg, gif, css, etc is sent to index.php) I'm adding code to the very start that does rename_function using a random hash -- said hash stored in a static private property of a filesystem singleton -- that then uses that singeton as a wrapper to restrict filetype access. Much like with multipart mail hashes, the odds of anyone guessing the rename hash is next to zero, making it a very secure way of allowing file extensions to be whitelisted or blacklisted.

In theory. Gah, PHP is so "insecure by design" it's ridiculous at times.

 

That usage I can actually agree on, but given such a broken host to begin with, I would assume that such a massive usage of SQL would get you slapped pretty quickly (given that you use this the same way you would an actual file-system, that is - storing videos, huge pictures and such). For small files, it would probably be okay.

 

Storing images and videos on a database must be, in any valid context, a very bad idea and a terrible architecture choice

 

Well, yes, but if you use this, that would be part of the usage, wouldn't it? Because if you're gonna leave images and video off the SQL filesystem-thingy, why use it at all? Then you'll have to use/modify two different systems for different file-types.

 

Maby this project is started to show that PHP can do such a thing, and maby in certain setups this could be used.. i have no idea what for kind of setups...

My first thought was.. "Just because it can..."