Benefits of using DB to store site layout/content?

[unsider]

I never really gave it much thought, but are there any positive benefits to this method?

 

I'm talking simply writing your layout code, or any code, into your DB as longtext, and then calling/outputting with a simply query.

 

 

 

[Highlander]

The only advantage is that you can have a Control panel to change the source for the site. But the downside is that you need to develop a framework for handling a requests, and generate all output every time (Client can't cache the data)

[JonnoTheDev]

Your database could end up massive! I would never use this approach. Use a template system.

[clikcspeed]

Well the MySQL and PHP combination to store site content works very well for me. I'm still a novie in web design and hence stilll assessing more of the benefits of the two technologies.

 

My first professional site which I'm almost finished with is for a local school, the site would be administered by people who don't have knowledge on how to do basic html but they would still need to make regular updates without having to use any code or WYSIWYG.

 

So with the help of a friend, I have designed an administration page where they can simply make changes to the content by typing into "text areas" and save, the data saved into the text area is saved into a db and it is this data which will be displayed on the main pages that the visitors can access...

 

Great benefits (...so far!)

[Minty]

Generally with 'content' I'd be inclined to write to a file rather than a database.

[cooldude832]

Your database could end up massive! I would never use this approach. Use a template system.

 

Not really I store a whole site in a database and it takes under a 1 mb 

 

MySQL is a great solution for storing a site because you can do so much more so easily with the data over a flat file

       

For example all my pages are made by a 6 step process

1) Url is rewritten to my index processor like index.php?page_request=example.php

2) The get var $_GET['page_request'] is queryered against the database if found it gets the pages content error else a 404 page message

3) The shell is collected out of mysql (top and bottom piece)

4) Shell top is loaded via Eval

5) Content loaded via eval

6) Shell bottom loaded via eval

 

Now advantages to my system is I can take my content area and pull keywords out of it based on tag structure (h1,h2, first words of paragraphs etc.) and then use those as my meta tag keywords for the page.

I can use the last updated time for that content area right out of mysql to satisfy that header

I can use my keywords to do fulltext searching quickly and effectively.

I have no requirements to manage any flat files so I can login and manage a site from any where I can get online

 

The only downside is the framework I wrote was 2 years of refining and still can be refined farther. But I have a passion for my CMS's framework so.

[ibechane]

If you're just using a database to store entries and not using the SQL capabilities of sorting, joining, comparing, etc., why not just store your data in an xml file?

 

For example:

<?xml>
<page>
  <title>my title</title>
  <section1>text that goes in section 1 div</section1>
  <section2><![CDATA[
    <b>html code</b> that <i>goes</i> in section 2 div
  ]]></section2>
</page>

 

Then use simplexml in your php script to pull out the nodes of the xml file and include them where ever you want, like in a template.  There's no mess.  The data is easily readable by a human and editable with just a text editor.  There's no need to log into a mySQL server everytime a page loads.  I'd be willing to guess that it's also faster and less CPU intensive for small amounts of data.  Also, since xml files are stored as files on your server, you can easily make a backup of your website and data by just copying all the files; no need to worry about saving db dumps.

[cooldude832]

xml u stil need a raw file unless you go database -> xml -> xhtml which just adds a step

 

I don't know where all these myth's came about about mysql being so slow would some one like to answer that?

[ibechane]

I'm not sure what you mean, cooldude.  I'm suggesting to use a php template that calls xml structured data instead of mysql database rows.  The speed aspect isn't the main reason I think xml is better.  Like I said, if you wanted to sort, search, join, compare data, I would definitely use mysql.  But for the purposes of just reading in structured data directly, xml seems like a simpler choice, and this seems like what the OP wanted.

[448191]

Storing templates in a DB is only useful if you need the templates to be editable via UI. If you have this requirement, use a DB. Otherwise, just use files.

[DarkWater]

xml u stil need a raw file unless you go database -> xml -> xhtml which just adds a step

 

I don't know where all these myth's came about about mysql being so slow would some one like to answer that?

 

The only thing about your approach that I completely disagree with is the use of eval() so much.  It's SO slow compared to normal PHP code execution.

[cooldude832]

the use of eval is not avoidable because I wanted to allow the users interface in the CMS to be able to use php.  any ideas on alternatives?

[corbin]

Do they do all kinds of things with PHP, or are they simply outputting variables?

[cooldude832]

everything and anything that is the point to allowing php in the CMS

[corbin]

Just making sure you aren't using eval just to output variables.  (That's my biggest issue with vBulletin.  They eval all of their DB template stuff just to do variable replacement.  Guess it's faster than str_replace....)

[cooldude832]

no a lot of the content area actually execute classes that are built around that page's content area to promote a consistent view.

 

I haven't noticed bad times on any pages yet for load using eval.

 

I also need it because my site does auto wiki links turning words into internal links.

 

However I might change that later and do smarties because they are going to be really tricky.