Welcome Guest, Not a member yet? Register   Sign In
Best practice for storing rarely modified data, e.g. lists?
#1

[eluser]charlieD[/eluser]
I was wondering what people think is the best practice for storing data that isn't modified by the user - in the database or in a config-type file?

Say, for example, I have 3 user types for a website. The app acts differently depending on which kind of user you are.

I could have a user_type table like so:
Code:
user_type:
  id:   integer
  name: varchar(30)
  desc: varchar(255)

Or, I could have a UserType.class.php file like so:
Code:
<?php

class UserType
{
    const STUDENT     = 1;
    const ASSISTANT = 2;
    const TEACHER    = 3;

    static public $descriptions = array(
        self::STUDENT    => 'Student',
        self::ASSISTANT  => 'Teaching assistant',
        self::TEACHER    => 'Teacher / Tutor',
    );
    
    static public $names = array(
        self::STUDENT    => 'student',
        self::ASSISTANT  => 'assistant',
        self::TEACHER    => 'teacher',
    );
}

Other examples are for storing things like lists, e.g. Film genres ('comedy', 'action', 'drama' etc.) that might appear in a <select> on a form - database or file?

In my eyes storing this information in a class file has a couple of advantages -
when you rebuild the database you don't lose the data or have the problem of the entries being assigned different IDs
it's easy to update from the text editor where you're working in anyway
fewer hits on the database

Would be grateful for thoughts on this and advantages/disadvantages of each approach.
#2

[eluser]slowgary[/eluser]
Expandability is easier using the database approach. If the site owner decided to add 'anime' to the film genres, your application could be written to allow addition of that category to the database. It's much less likely your application would be written to write new code into itself.

If the data will NEVER change and you can be 100% sure of it, I don't see a huge problem with it being defined in code. The code is only defining the available options though, you'd still need to store and manage instances of your objects in something like a database.

For security, especially on the web, I often find myself storing things in my left sock (if I'm wearing socks, otherwise - undies).
#3

[eluser]jedd[/eluser]
I've tended to move this stuff, more and more, into the database - for a variety of reasons. Portability, as you observe, but also the pragmatic response to the increasingly obviously ludicrous claims (made by users) that 'this data will never be changed', and 'we'll never have more than x types of y', and 'we'll never need a web interface to manage these data' .. and so on. You also get the benefit of being able to do SQL calls (joins, unions, etc) that involve the data - something you can't do if the data isn't in the database.

If you use a model to retrieve these data then you can later modify the storage method and your application doesn't need to know where and how it's stored.

My feeling with the particular example you've used here is to put it in a config file and use the CI config class to retrieve the data.
#4

[eluser]NogDog[/eluser]
[quote author="jedd" date="1241084483"]...If you use a model to retrieve these data then you can later modify the storage method and your application doesn't need to know where and how it's stored....[/quote]
Excellent point. As long as whatever method you use is encapsulated within a class which takes care of all retrieval/storage issues, you can change your mind whenever you want and rest assured the rest of the application won't care.




Theme © iAndrew 2016 - Forum software by © MyBB