---
title: "Flat file systems versus database models for help"
date: 2014-11-05
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2014/11/05/flat-file-systems-versus-database-models-for-help/
---
# Flat file systems versus database models for help
I found the post extremely interesting because I've been moving back and forth between flat-file systems and database systems with my DITA publishing strategies. There are compelling arguments for each side.

On one hand, databases provide more capability to delivery dynamic content to different users who come to the same site. With flat-file systems, it's much harder to dynamically serve up the content, so you may end up with numerous outputs if your content warrants different information for different audiences. On the other hand, flat-file systems are much easier to deploy. They fit into the developer's workflow, can easily be added to any server, and almost never pose security or other restrictions on access.

I have so much to say on this topic. I'll try to maintain some order to my thoughts.

## What *are* flat file systems created with static site generators?

First, by "flat-file systems," we're talking about regular websites with individual pages, as in the days before WordPress, Drupal, Joomla, and other database-driven web CMS's spring up. But now there are scores of static file generators popping up: Ghost, HTMLy, Jekyll, Wintersmith, Nano, Pico, Kirby, PhileCMS, Get Simple CMS, Octopress, Docpad, Statamic, Flatpress, and [many, many more](https://staticsitegenerators.net/).

The static file generator works somewhat like a help authoring tool works -- it compiles all the files into a website output.

Static site generators (such as Jekyll) are extremely popular in API doc spaces because these flat files can travel with code and live in version control repositories, such as Github. Developers accustomed to writing code in flat files can open their same text editor, jot down some information using Markdown syntax, and initiate site builds with a few words in the command-line. Static site generators fit into their workflow and world.

Proponents of static site generators revel in simplicity. They say WordPress has become too generalized, with too many features, heavy database calls, infrastructure, unnecessary components, and more. In contrast, static flat files are quick and easy, secure, lightweight, and efficient.

On the other hand, database-model CMS's like WordPress can do things that static site generators can't. In a few minutes you can integrate plugins that do advanced things (for example, which restrict access, or assign roles to users, or roll-up site-wide comments). There are literally 30,000+ plugins already available. You can find a gorgeous theme, install it, and configure it in about half an hour. Over the course of a weekend, you can have a fully developed, modern-looking site (or even a social network, or forum, or multimedia site) without being a web developer.

While static site generators are simple, you won't find the same number of plugins and themes at your ready disposal to crank out that awesome website over the weekend. Instead, it will be simple to implement the default site and maybe several different themes, adding a few extensions. But then anything more sophisticated will probably require you to "roll your own," as they say.

Further, with each update to your site, you'll need to regenerate and redeploy the site. You can trigger the rebuilding through some scripts to make the process more automated, but this may require some advanced skills.