Question

Well, this architectural issue has been wandering in my mind for a while. Suppose the following scenario:
I have a Licenses table. Conceptually, each license can be limited to (License Types):

• Type 1: Number of tries. (e.g. allowing to run 7 times)
• Type 2: Trial (Time-limited).
• Type 3: Full
• …

So, each license should store some custom value. (Type 1: Integer, Type 2: DateTime, Type 3: null)

What’s the best architecture for this scenario?

• If I decide to put all the licenses in one table, I have at least 1 unused column for every row (EndDate would be null for Type 1, TryTimes would be null for EndDate and both would be null for Type 3):
  LicenseID---LicenseType---CustomerID---EndDate---TryTimes
  On the other hand, I’d like my design to be as flexible as possible (Maybe more license types in the future?)
• Another possible solution would be using some metadata-like approach:
  LicenseID---LicenseDefinition---CustomerID---
  Where LicenseDefinition contains information about the type and limit of the license and is parsed on the code side.

Which one do you suggest to be more conventional? Do you suggest any other way to implement it?

UPDATE:
Just found out about Sparse columns is SQL Server. Sounds very promising…

Answer 1

Off the top of my head (I haven’t implemented anything like this yet), I might do something like this:

Create database tables for Customer and License. Within Customer, along with all of the other generic customer information I would add a column for licenseType, which would reference the License table.

License would store the licenseId as well as any relevant meta data. This would not include license-specific rules.

On the code side, I would create a LicenseFactory class which would create an instance of a license interface (ILicense). ILicense might look something like this (in PHP):

interface ILicense
{
    public isValid($customer);
}

Then, I would have license-specific implementations:

class TrialLicense implements ILicense
{
    public isValid($customer)
    {
        // business logic for this specific license type here
    }
}

The factory class would look something like:

class LicenseFactory
{
    public static function getInstance($type)
    {
        switch($type)
        {
            case 0:
                return new TrialLicense();
                break;
        }
    }
}

So now, my application code might look something like this:

public function isLicenseValid($customer)
{
    return LicenseFactory::getLicense($customer->licenseType)->isValid($customer);
}

None of this has been tested and are just my (rather long winded) initial thoughts. Hope it helps a little though (even though your app may not be php driven :))

Edit:
Forgot to mention – the power in this approach is the extensibility. Any time you want to add a new license type, you’d simply add a new row to the License table and a new ILicense implementation with whatever business rules are required.