title: One big MySQL DB or a thousand little SQLite databases?
body: <p>I am working on a Web based organisation tool. I am not aiming the same market as the wonderful Basecamp, but let's say the way users and data interact look like the same. </p>
  
  <p>I will have to deal with user customisation, file uploads and graphical tweaks. There is a fora for each account as well. And I'd like to provide a way to backup easily each account.</p>
  
  <p>I have been thinking how to create a reasonable architecture and have been trained to use beautifully normalized data in a single (yet distributed if needed) MySQL DB. Recently I have been wondering :
  is it possible to think about using one SQLITE DB to store the data  for each account and only use MYSQL for the general web site management ?</p>
  
  <p><strong>The pro :</strong></p>
  
  <ul>
  <li>backing up is straightforward  : set version, zip, upload.</li>
  <li>don't bother if each account use a massive fora : the mess is in one file for every one of them.</li>
  <li>SQLITE is lightening fast, no expensive connection time...</li>
  <li>Table scheme is much simplier : no need to make any distinction between account every times</li>
  </ul>
  
  <p><strong>The cons :</strong></p>
  
  <ul>
  <li>don't know if it's scalable</li>
  <li>don't know if the hard drive will keep up</li>
  <li>don't know if there is a way for SQLITE to not be stored in RAM since it would be quickly a disaster</li>
  <li>lots of dir and subdirs : will this be ok ?</li>
  <li>maintenance issue : upgrading the live site means upgrading all the db one by one</li>
  <li>dev issue : setting a dev / pre prod / prod env will be quite hard</li>
  <li>commom data will still require using mysql, so we would end end with 2 DB connections for each page, arg</li>
  </ul>
  
  <p>More cons that pros, still, it makes me wonder (zepplin style).</p>
  
  <p>What do you say ?</p>