Users Table Structure

For all applications a solid database design is absolutely essential, for small applications, a well designed database may mean the application is practically done.

Almost all applications require a users table which tends to be overly bloated. A typical structure looks something like this

Now this is all good but this has several flaws

  • The table has to be changed whenever any of the attributes changes
  • The table and any helper files you may have (models, migrations, forms, controllers etc) are not reusable across your different projects
  • You can not easily test access control functions
  • You will end up with a lot of “ifs” to determine existence of data or even worse role the user plays.

We need to clean this up to a couple of separate tables like this

This finally leaves us with clean and reusable structure


You should consider applying the same concepts to all your tables, general rule should be if a table has any group of attributes that you seem to use a lot together, strip them out and build a new table for them.

Till next time. Happy coding!





Setting up papertrail on forge.

Looking for log files can be quite a hustle. Fortunately forge  ( ) + papertrail (  )makes this a downright simple process. Assuming you already have an active forge and papertrail

Step 1:

Create a new logging system in papertrail

Take note of your specific link.

Hint: It is the content in large text***.
Step 2:

Login to your forge installation.

Select the server you want to manage and then navigate to the monitoring tab.

There is an option for papertrail. Paste in your link and click install.

Step 3:

Navigate back to papertrail and wait till your server shows up on the “All Systems” list.

And you are good to go. Happy logging!!


The Final Word

Among the list used keywords in php is “final”

The definition from

PHP 5 introduces the final keyword, which prevents child classes from overriding a method by prefixing the definition with final. If the class itself is being defined final then it cannot be extended.

If you are anything like me, then your first thought must have been why would I want to kill inheritance and polymorphism. This does seem like a needless, neigh, a downright harmful operation. However this keyword plays a very important role in your application design.

One use case is where you would want to carry out the Introduce Parameter Object Refactor .

Our original class looks like this:

Once we have refactored:


So far all is well. Now imagine way into the future, you decide to make the date output a bit more user friendly, and being a good developer you extend the DateRange class with a new method

While all may look well. This bit of code will break all classes that used it as parameter!

When you really think about it, you realize that DateRange had no business being extended and should have been treated as a primitive object, just like the parameters it replaced.

As such this class should be declared final to protect it from further meddling and even more importantly to ensure consistency of your code.