Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Our production environment includes the following:</p> <ul> <li>3 frontends who serve our website</li> <li>2 database backends (Master-Slave, replication)</li> <li>1 mixed which runs httpd and database for adserving</li> </ul> <p>Our development environment is a single server running both database and httpd, configuration-wise we have different workspaces for everyone setup and our VC is subversion. Staging is rather simple too - it runs on one of the frontends.</p> <p><strong>Database changes</strong></p> <p>Initially we spent a lot of time on the database design and it seems to have really paid off. We haven't changed anything major in five months now. Most of the changes we deploy are on the frontend. Now, so far we run all the changes to the database manually and I always wrote a small script to revert.</p> <p>If I had more of those, I'd use <a href="http://www.doctrine-project.org/" rel="nofollow noreferrer">Doctrine</a> and <a href="http://www.doctrine-project.org/projects/migrations.html" rel="nofollow noreferrer">Migrations</a> here. I've never actually had the chance to use them in production but I've played with those extensively already and they seem very powerful.</p> <p><strong>Deployment</strong></p> <p>So whenever we deploy a new version we create a tag of the code which we check out on staging, then go through a couple lists of checks etc. and then we deploy the code on the production frontends. For doing all of the deployment, I have a couple tasks setup in <a href="http://capistranorb.com/" rel="nofollow noreferrer">Capistrano</a>.</p> <p>Check out this sample <code>capfile</code>:</p> <pre><code>role :www, "web01", "web02", "web03" role :web, "web01", "web02", "web03", "web04" role :db, "db01", "db02" desc "Deploy sites" task :deploy, :roles =&gt; :www do run "cd /usr/www/website &amp;&amp; sudo svn --username=deploy --password=foo update" end </code></pre> <p>Capistrano also allows you to run any other command without defining a task:</p> <pre><code>cap invoke COMMAND="uptime" ROLES=web </code></pre> <p>(Requires the <em>role</em> "web" to be setup. See example above.)</p> <p><strong>Coding style and documentation</strong></p> <p>We pretty much adhere to the <a href="http://pear.php.net/manual/en/standards.php" rel="nofollow noreferrer">PEAR Coding standard</a>, which we check using <a href="http://pear.php.net/package/PHP_CodeSniffer" rel="nofollow noreferrer">PHP_CodeSniffer</a> (phpcs). When I say pretty much, I mean that I forked the sniffs provided and added a few exceptions of my own gusto.</p> <p>On top of coding style, phpcs checks on inline documentation as well. This documentation is created by <a href="http://phpdoc.org/" rel="nofollow noreferrer">phpDocumentor</a> in the end.</p> <p><strong>CI</strong></p> <p>I have both of those tools setup in our CI-server (<strong>continuos-integration</strong>), which is <a href="http://phpundercontrol.org" rel="nofollow noreferrer">phpUnderControl</a> using the above and CruiseControl, <a href="http://phpunit.de" rel="nofollow noreferrer">phpUnit</a>, <a href="http://xdebug.org" rel="nofollow noreferrer">Xdebug</a> (a couple code metrics...), etc..</p> <p>unit-testing is something we currently lack. But what we do right now is that with each bug we find in our parsing engine (we parse text into certain formats), we write a test to make sure it doesn't come back. I've also written some basic tests to check the URL-routing and the internal XMLRPC API but this is really subject to improvement. We employ both phpUnit-style tests and <a href="http://qa.php.net/write-test.php" rel="nofollow noreferrer">phpt</a> as well.</p> <p>The CI-server <em>builds</em> a new version a couple times per day, generates graphs, docs and all kinds of reports.</p> <p>On top of all of the tools mentioned, we also use Google Apps (primarily for email) and keep a Google Sites wiki with all other documentation. For example, deployment procedure, QA test lists, etc..</p>
    singulars
    1. This table or related slice is empty.
    1. POSetting up a PHP web project, the infrastructure
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USj0k
    1. USTill
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSetting up a PHP web project, the infrastructure
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis is *exactly* what I was interested in! I don't have time to read it right now but thanks, I can't wait to sit down and read it properly.
      singulars
      1. PO
      1. USnoob source
    2. COYou're welcome. Let me know if you have any other questions.
      singulars
      1. PO
      1. USTill
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload