0

How should necessary data that is stored in the database be referenced throughout code? Is it better to reference a numeric, auto-incrementing ID, or a unique alphanumeric key/name, etc.? For example:

  • Determining page display based upon a specific setting/value from, say, a Settings database table
  • Retrieving a maximum value stored in the database for displaying a list of items on a page

Is it a good practice to define constants in code to reference these things, such as the following? Or is there an entirely better approach?

/* Code to define constant references */

// Numeric, auto-incrementing ID?
define('SETTING_A', 134);
// Or unique name?
define('SETTING_B', 'PageDisplaySetting');

/* Code to retrieve settings/values */

$settingA = $db->query('SELECT Value FROM Settings WHERE ID = ' . SETTING_A);
$settingB = $db->query('SELECT DisplayMaxItems FROM Table WHERE ID = ' . SETTING_B);
// etc.

/* Code to render display based upon these settings/values */
...
  • 1
    Use the numeric IDs only for joins and make your business agnostic to these "magic numbers". Use the key-value approach for programming and modelling. It will make your life easier. – Laiv Nov 23 '17 at 21:49
1

Regarding the ID vs. key question: your settings seem to be essentially key-value pairs. So representing them with a SettingKeyand SettingValue seems to be the most natural way to go. The keys should be defined somewhere, just like you proposed.

Also, you should probably hide the fact that they are stored in a database. I think you have two reasonable options for doing this:

  1. A settings object, e.g.

    class Settings
    {
        var $entries_per_page;
        var $date_format;
    }
    

    with a loadSettings() function that returns an instance of the Settings class. You can then load the settings at the beginning and pass that object around where needed, or store it globally. Then you access the values just via $mySettings->entries_per_page.

    You can expand on this as needed, e.g. making the fields private and providing getters, have alternative loadSettings() functions, if you want to switch to text files instead of a DB, or go for a SettingLoader class/interface etc.

  2. Load as needed, with a getSetting($settingKey) function. This function can then execute the necessary query.

Option 1 has the advantage that you can load everything in one database call. Option 2 has the advantage that you can load only what you need, but you will have to make multiple queries. Unless you have a huge amount of settings that you only rarely access, I would recommend option 1.

In any case, retrieving the settings should be hidden in your loadSettings or getSetting function. To the rest of the application, there should just be a way to access values based on pre-defined keys.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.