Question

What is the best way to store settings for certain objects in my database?

1. Method one: Using a single table
   Table: Company {CompanyID, CompanyName, AutoEmail, AutoEmailAddress, AutoPrint, AutoPrintPrinter}

2. Method two: Using two tables
   Table Company {CompanyID, COmpanyName}
   Table2 CompanySettings{CompanyID, utoEmail, AutoEmailAddress, AutoPrint, AutoPrintPrinter}

Answer 1

I would take things a step further…

Table 1 – Company

CompanyID (int)
CompanyName (string)

Example

CompanyID 1
CompanyName "Swift Point"

Table 2 – Contact Types

ContactTypeID (int)
ContactType (string)

Example

ContactTypeID 1
ContactType "AutoEmail"

Table 3 Company Contact

CompanyID (int)
ContactTypeID (int)
Addressing (string)

Example

CompanyID 1
ContactTypeID 1
Addressing "[e-mail]"

This solution gives you extensibility as you won’t need to add columns to cope with new contact types in the future.

SELECT
   [company].CompanyID,
   [company].CompanyName,
   [contacttype].ContactTypeID,
   [contacttype].ContactType,
   [companycontact].Addressing
FROM
   [company]
INNER JOIN
   [companycontact] ON [companycontact].CompanyID = [company].CompanyID
INNER JOIN
   [contacttype] ON [contacttype].ContactTypeID = [companycontact].ContactTypeID

This would give you multiple rows for each company. A row for “AutoEmail” a row for “AutoPrint” and maybe in the future a row for “ManualEmail”, “AutoFax” or even “AutoTeleport”.

Response to HLEM.

Yes, this is indeed the EAV model. It is useful where you want to have an extensible list of attributes with similar data. In this case, varying methods of contact with a string that represents the “address” of the contact.

If you didn’t want to use the EAV model, you should next consider relational tables, rather than storing the data in flat tables. This is because this data will almost certainly extend.

Neither EAV model nor the relational model significantly slow queries. Joins are actually very fast, compared with (for example) a sort. Returning a record for a company with all of its associated contact types, or indeed a specific contact type would be very fast. I am working on a financial MS SQL database with millions of rows and similar data models and have no problem returning significant amounts of data in sub-second timings.

In terms of complexity, this isn’t the most technical design in terms of database modelling and the concept of joining tables is most definitely below what I would consider to be “intermediate” level database development.