Question

I have an application where it seems as if it would make sense to store some records hard-coded in the application code rather than an entry in the database, and be able to merge the two for a common result set when viewing the records. Are there any pitfalls to this approach?

Firstly, it would seem to make it easier to enforce that a record is never edited/deleted, other than when the application developer wants to. Second, in some scenarios such as installing a 3rd party module, the records could be read from their configuration rather than performing an insert in the db (with the related maintenance issues).

Some common examples:

                                       In the application        In the database
-----------------------------------    ------------------        ----------------------
customers                              (none)                    all customers
HTML templates                         default templates         user-defined templates
'control panel' interface languages    default language          additional languages
Online shop payment processors         all payment processors    (none)

So, I think I have three options depending on the scenario:

1. All records in the database
2. Some records in the application, some records in the database
3. All records in the application

And it seems that there are two ways to implement it:

1. All records in the database:
   • A column could be flagged as ‘editable’ or ‘locked’
   • Negative IDs could represent locked values and positive IDs could represent editable
   • Odd IDs represent locked and even IDs represent editable…
2. Some records live in the application (as variables, arrays or objects…)

Are there any standard ways to deal with this scenario? Am I missing some really obvious solutions?

I’m using MySQL and php, if that changes your answer!

Answer 1

In general, anytime you’re performing a database query if you want to include something that’s hard-coded into the work-flow, there isn’t any joining that needs to happen. You would simply the action on your hard-coded data as well as the data you pulled from the database. This is especially true if we’re talking about information that is formed into an object once it is in the application. For instance, I can see this being useful if you want there to always be a dev user in the application. You could have this user hard-coded in the application and whenever you would query the database, such as when you’re logging in a user, you would check your hard-coded user’s values before querying the database.

For instance:

// You would place this on the login page
$DevUser = new User(info);
$_SESSION['DevUser'] = $DevUser;

// This would go in the user authentication logic
if($_SESSION['DevUser']->GetValue(Username) == $GivenUName && $_SESSION['DevUser']->GetValue(PassHash) == $GivenPassHash)
{
    // log in user
}
else
{
    // query for user that matches given username and password hash
}

This shows how there doesn’t need to be any special or tricky database stuff going on. Hard-coding variables to include in your database driven workflow is extremely simple when you don’t over think it.

There could be a case where you might have a lot of hard-coded variables/objects and/or you might want to execute a large block of logic on both sets of information. In this case it could be beneficial to have an array that holds the hard-coded information and then you could just add the queried information to that array before you perform any logic on it.

In the case of payment processors, I would assume that you’re referring to online payments using different services such as PayPal, or a credit card, or something else. This would make the most sense as a Payment class that has a separate function for each payment method. That way you can call whichever method the client chooses. I can’t think of any other way you would want to handle this. If you’re maybe talking about the payment options available to your customers, that would be something hard-coded on your payment page.

Hopefully this helps. Remember, don’t make it more complicated than it needs to be.