A great Rhetorical question about databases 1

[vcherubini]

Hey guys:

My friend and I were kinda having this argument about HTML and storing it in a database for a site. I think that the data should be stored in there seeing as it is static, and does not need to change. I also think that the HTML for my site should be stored in there because it makes having themes for the site easier. Would you agree? If you have 5 different themes and you store the HTML for them in a database, then when a user logs in, the script can call a get_template() type of function to pull the theme that the user specifies. Is this the best way to do something or am I missing something about database programming. (I'm probably missing a lot since I have not been doing it that long. ).

Is there a better way to do this theming thing?

Any help to put an end to this argument is appreciated.

Thanks,

-Vic vic cherubini
vikter@epicsoftware.com

http://www.epicsoftware.com

====
Knows: Perl, HTML, JavScript, C/C++, PHP, Flash, Director
====

 

[goBoating]

I tend to view the decision about when/wether to use an
RDBMS in terms of what does an RDBMS do that text/xml/html
files won't. And, what part of that do I need.

All competent operating systems must find, open,
read, and write files efficiently. So, it follows that
the use of flat files to store data is not inherently
inefficient. The way you ask the OS to use files may be
inefficient. Even as flat file systems grow, simple indexes
can be built to deliver impressive search speed.

So, what do RDBMS's do that flat files won't?
1 - support multiple simultaneous users of a single data set
2 - support the efficient management of complex data sets
3 - support the searching/serving of really large(huge)data sets
4 - deliver tools to control data security and integrity

Why not always use an RDBMS?
1 - Such systems usually carry an associated cost due to
purchase and/or setup and/or maintenance. Flat files are free.
2 - The system resources required to run an RDBMS are sometimes
significant. If you already have one running for other
reasons, then this is not a consideration.
3 - The human resources to needed to deal with a database can be
significant and expensive.
4 - There is significant overhead associated with connecting to
a database server and communicating with it from with in a
piece of code. Often, a flat file approach uses far less
system resources and can be faster.

So, if your data set is really complex or large or you just want to learn, then
a competent database server would help. However, if your data
set is small and is two deminsional or close to
two dimnesional, then flat files might be a better option.

For spitting out HTML, I believe the system resources required
to read and output flat files would be far less than those required
to spin an RDBMS, connect to it from within your application,
request the HTML and then print the same HTML you could have
pulled from a flat file.

Additionally, you can split the difference and employ the Perl
DBI/DBD approach on flat files with DBD::CSV. That way, if
your performance begins to suffer or you need to expand the
function of the system beyond what the flat file approach will
do well, you can switch to a different driver (DBD::MySQL or
Sybase or ... or ... or ....) and your code will be easily
tweaked to deal with the new database. This would have the
advantage of putting off the complexities of caring for a database
until you were ready and wanted to.

'just my two sense... or scents(no, that smells) or maybe cents...


keep the rudder amid ship and beware the odd typo