On 10/12/2010 11:06 AM, Adrian Crum wrote:
On 10/12/2010 8:55 AM, Adam Heath wrote:
On 10/12/2010 10:25 AM, Adrian Crum wrote:
Actually, a discussion of database versus filesystem storage of
content
would be worthwhile. So far there has been some hyperbole, but few
facts.
How do you edit database content? What is the procedure? Can a simple
editor be used? By simple, I mean low-level, like vi.
How do you find all items in your content store that contain a certain
text word? Can grep and find be used?
How do you handle moving changes between a production server, that is
being directly managed by the client, and multiple developer
workstations, which then all have to go first to a staging server? Each
system in this case has its own set of code changes, and config+data
changes, that then have to be selectively picked for staging, before
finally being merged with production.
What about revision control? Can you go back in time to see what the
code+data looked like? Are there separate revision systems, one for the
database, and another for the content? And what about the code?
For users/systems that aren't capable of using revision control, is
there a way for them to mount/browse the content store? Think nfs/samba
here.
Storing everything directly into the filesystem lets you reuse existing
tools, that have been perfected over countless generations of
man-years.
I believe Jackrabbit has WebDAV and VFS front ends that will accommodate
file system tools. Watch the movie:
http://www.day.com/day/en/products/crx.html
Front end it wrong. It still being the store itself is in some other
system(database). The raw store needs to be managed by the filesystem,
so standard tools can move it between locations, or do backups, etc.
Putting yet another layer just to emulate file access is the wrong way.
<brainstorming>
Let's make a content management system. Yeah! Let's do it! So, we need
to be able to search for content, and mantain links between
relationships. Let's write brand new code to do that, and put it in the
database.
Ok, next, we need to pull the information out of the database, and serve
it thru an http server. Oh, damn, it's not running fast. Let's have a
cache that resides someplace faster than the database. Oh, I know,
memory! Shit, it's using too much memory. Let's put the cache in the
filesystem. Updates now remove the cache, and have it get rebuilt. That
means read-only access is faster, but updates then have to rebuild tons
of stuff.
Hmm. We have a designer request to be able to use photoshop to edit
images. The server in question is a preview server, is hosted, and not
on his immediate network. Let's create a new webdav access method, to
make the content look like a filesystem.
Our system is getting heavily loaded. Let's have a separate database
server, with multiple web frontends. Cool, that works.
The system is still heavily loaded, we need a super-huge database server.
Crap, still falling over. Time to have multiple read-only databases.
</brainstorming>
or...
<brainstorming>
Let's store all our content into the filesystem. That way, things like
ExpanDrive(remote ssh fs access for windows) will work for remote hosted
machines. Caching isn't a problem anymore, as the raw store is in files.
Servers have been doing file sharing for decades, it's a well known
problem. Let's have someone else maintain the file sharing code, we'll
just use it to support multiple frontends. And, ooh, our designers will
be able to use the tools they are familiar with to manipulate things.
And, we won't have the extra code running to maintain all the stuff in
the multiple databases. Cool, we can even use git, with rebase and
merge, to do all sorts of fancy branching and push/pulling between
multiple development scenarios.
</brainstorming>
If the raw store was in the filesystem in the first place, then all this
additional layering wouldn't be needed, to make the final output end up
looking like a filesystem, which is what was being replaced all along.
