Christopher Murtagh wrote, On 04/07/2007 09:42 PM:
Yes, this would also work fine. Our differences here are simply one of philosophy. Both approaches (files in filesystems vs fields in database) will work. We agree to disagree... (grin)Agreed... or is that disagreed? :-) After having worked on large systems like this, I prefer to keep code and user content in their own places. From my experience, it makes foreasier maintenance and backups.
My 5 cents of experience from systems like this is that it isn't black and white.
Default values "are" a kind of code. When systems are upgraded then default values in use could/should be upgraded as well. The file system is a natural place for these.
Customizations made through the web are obviously user content and should be stored in the database. The (implicit) choice to use the default values could be considered "user content" as well (or at least some kind of data that could be stored in the database).
(And some users will in some cases prefer to make customizations in the file system, even though the customized files are data really belongs in the database...)
I have found that the best compromise is to first search for data (e.g. templates) in the database and then - if not found - fall back to the file system. Perhaps with a number of "layers" both places.
(Another interesting approach could be to propagate changes to "the other place" whenever something changes. But that could easily end up with collisions where both versions has been changed and can't propagate without loosing data...)
there's more than one way to do it - that's the perl motto after all.
- but there might be more than one way anyway ;-) /Mads