title: Best practices to structure a database to be scaling-ready
body: <p>I know this is a very generic and subjective question, so feel free to vote to close it if it does not meet the StackOverflow netiquette.. but for me, it's worth trying ;)</p>
  
  <p>I've never built a high-traffic application since now, so I'm not aware (except for some reading on the web) about scaling practices.</p>
  
  <p><strong>How can I design a database that, when a scaling is needed, I dont have to refactor the database structure, or the application code?</strong></p>
  
  <p>I know that development (and optimization) should come step-by-step, optimize bottleneck as they happen, and is nearly impossible to design the perfect structure when you don't know how many users you'll have and how would they use the database (e.g. read/write ratio), I'm just looking for a good base to start.</p>
  
  <p>What are the best practices for making a structure almost ready to be scaled with <code>partitioning</code> and <code>sharding</code>, and what <code>hacks</code> must be absolutely avoided?</p>
  
  <p><strong>Edit</strong> some detail about my application:</p>
  
  <ol>
  <li>The application will run as a multisite behavior</li>
  <li>I'll have a database for each application version (db_0_0_1, db_0_0_2, etc..)*</li>
  <li>Every 'site' will have a schema inside a database* and a role that can access only his own schemas</li>
  <li>Application code will be mostly PHP and few things (daemons and maintenance things) in Python</li>
  <li>Web server will probably be Nginx and lighttpd or node.js as support for long-polling tasks (e.g. chat)</li>
  <li>Caching will be done with memcached (plus apc for things strictly related to the php code, as it can be used outside php)</li>
  </ol>