TR Forums

So I got this crazy idea.

I'm writing a simple blog site, and I want to be able to use a single data source, which my scripts (PHP) then use to generate XHTML pages, RSS feeds, e-mail formatted messages, et cetera. Now, I started to write it using PHP+MySQL, but I started running into problems; for example, in my RSS feeds I want to show different content than on my main site, some of my articles contain executable PHP code (Yeah, I know, it's jackass, but I want it there. My website after all.) and SQL just seems a bit messy to me. It works great for some things, but... a personal blog?

So I thought, 'why not store everything in an XML file, let PHP process that file to deal with any generated tidbits I put in the posts, and then use an XML stylesheet to format the content for whatever I want to display?' I then shot down my own idea by saying "well, not all browsers will support XSLT..." but then I again realized that I could use PHP to perform the transformations for me.

Is there any reason this is jackass? I was thinking I'd keep the file inside my /includes/ folder, which is only accessible to the server host itself (as per my .htaccess file). As of now I don't see any reason to not manually exit the XML and upload it periodically, but it shouldn't be an issue to write a script which writes to the XML file later.

Am I being dumb? Am I a genius?

i don't understand why you can't use a SQL database too do this anyhow - XML shouldn't really offer any advantages in this area. If you want different content for RSS just make a new column for it in the same table as the regular content and use the ID as your unique identifier. So simplifying things maybe you have a table with rows ID, CONTENT, RSSCONTENT and pull from there. A database will also be much more easily maintained and updated etc. Consider long term content updates when you have more than 50+ articles. That 1 XML file is going to get ugly.

I'm reminded of this blog entry: http://www.codinghorror.com/blog/archives/001114.html. Not purely relevant to your case, but a worthwhile read anyways.

But in the end, I come to this logic: if XML can do it, a real database can do it, and probably do it better. Databases have a HUGE speed advantage compared to large XML files. And if you decide to go with multiple small XML files, i.e. a single file per entry, well then you end up with having to deal with multiple files, and trying to keep them all in sync, etc. At the very least, you can store the XML text inside a text field in the database, then apply transforms after when you get the data back out.

Seems to me that the root of your problem is designing an adequate table structure. Take some time, sit back and think things through, then fully diagram out what you think your database should look like. In any project involving a database, hammering out a complete database design, and then implementing that design is the very first thing I do before I start any of the more front end stuff so that I have a solid foundation to build up from.

People tend to overuse XML, some think it's the solution to all world problems, well it's not