Question: I am having the strangest time with the following PHP code. The require\_once runs in the else statement even though the if statement is true. What is also strange is that $controller in the else statement recieves the value of "application." There is no other code related to the following other than $total's value.

```
    $total = $uri->total();

    if($total == 0) {

        //Home Page Controller
        $controller = 'index';
        $method = false;

    } else {

        $controller = $uri->segment(1); //value is "account"

        if($uri->segment(2) !== false) {
            $method = $uri->segment(2); //value is "login"
        } else {
            $method = false;
        }
    }

    require_once(APPPATH.'controllers/'.$controller.EXT);

    $$controller = new $controller;

    if($method != false) {
        $$controller->$method();
    } else {
        $$controller->index();
    }

```

Edit: I fixed the double-code so that the same code is not called twice in either the if or the else. When I run this, the code works, but I get an error on the line where the require\_once is: cannot find application.php

This is strange because require\_once is already loading the correct class, but I am getting an error that it cannot find the right file. What would cause it to load twice? I've checked to make sure the file this PHP is in doesn't load twice.

This is all the code I am working with except the URI class found here: <https://github.com/chrisabrams/PHP-URI-Class>

I am not sure where application.php comes from.

Answer: 
On occasion it's useful for table locks. When you add a column to a database, the whole table gets locked until it's fully rewritten. This has little to no impact when your database has 100k rows. But if you've 100M rows, or 1B rows, it's a whole different story...

It's also useful to avoid dead rows that take too much space. If you're using [MVCC](http://en.wikipedia.org/wiki/Multiversion_concurrency_control) and some of your columns are regularly overwritten, it occasionally makes sense to place them in a separate table. Arguably, auto-vacuuming eventually kicks in, but for the sake of sparing hard drive work, better vacuum a few int fields in a separate table than a whole bunch of entire rows full of text, varchar(n) and who know what else.

A last reason would be the abuse of `select *` in ORMs. If you're storing images or blog posts/articles, for instance, it may make sense to store the blob/text field in a separate table. Because every time it gets loaded for a reason or the other, your ORM is going to load the whole row. When you only need the URL of your image or post, the last thing you want is to pull the whole binary/text from the database; and yet your ORM will do just that...
One reason would be to put frequently accessed data in one table and extremely rarely accessed data in another table. It would run faster and save some memory.

But I would have to have my arm twisted hard before I would do it.