SQL performance width versus depth - sql

Question

I have a customers table that holds information about customer prefrences like if he wants to receive a newsletter and so on. If he/she wants to receive a newsletter, the value is stored in the column "customerNewsletter" and set to true. However I have a couple of these bit values and parameters that are in a column of there own. I store dates, true/false, integers and tekst like this for each customer.
I find that about 80% of my customers wants to receive a newsletter and that makes that 80% of the values is set to true. I now store a value for each customer set to false or true. What if I only should have to store the 20% set to false ??
There is a list of about 20 of these parameters that I could include as a column (they are now), but I was wondering if there is a better way.
So I create 3 tables to hold these parameter values, a param table holding the actual value, a paramsNames table, that holds the names of the values and a params table that connects the parameters to a customerID
SELECT
customerParamsName as [Name],
customerParamText as [Text],
customerParamINT as [int],
customerParamsDateTime as [Date]
FROM db14.customerParams
INNER JOIN db14.customerParam ON customerParamsChildID = customerParamID
INNER JOIN db14.customerParamsNames ON customerParamNameID = customerParamsNameID
This would give me
Name Text int Date
Phonenumber NULL 615164898 2013-09-20 00:00:00.000
Can anyone tell me if this is a good way to go, or are there more common ways of storing Multi-Type parameters more efficiently ?
AFTER some MORE consideration
I have created 2 tables
customerParam
paramID paramNameID ParamParentID paramChildID paramText paramINT paramDate
INT TINYINT INT INT varchar(24) INT DATETIME
PRIMARY INDEXED
customerParamNames
paramNameID paramName
TINYINT VARCHAR(24)
PRIMARY
1 'FirstName'
2 'LastName'
3 'Email Address'
4 'Phonenumber'
5 etc..
Let's say I want to store the firstName and LastName
I create records in customerParam for both values ;
paramID paramNameID ParamParentID paramChildID paramText paramINT paramDate
17456 1 'John'
17467 2 'Doo'
17468 1 752 17456
17469 2 752 17467
As I expect more occurrences for the name ‘John’ I am storing it as an independent value, then joining it using the parentID/ChildID combination.
and for the phoneNumber
17470 4 752 31615164899
17471 5 752 'me#here.com'
The phonenumber is very explicit to this customer, I am using the parentID to join it straight to the customer. The same goes for the emailaddress.
At this time this solution looks like the way to go... I am also still looking at the xml approach but I don’t have a good understanding on how to use XQuery and xmlDocuments stored in a database.
And It seems like a lot of overhead.
I will move forward with the solution above... until someone gives me a better one.
Example SQL
DECLARE #paramNames TABLE (paramNameID TINYINT, paramName varchar(24))
DECLARE #param TABLE (paramID INT, paramNameID TINYINT, paramParentID INT, paramChildID INT, paramText varchar(24), paramINT INT, paramDate datetime)
INSERT INTO #paramNames VALUES ( 1, 'firstname')
INSERT INTO #paramNames VALUES ( 2, 'lastname')
INSERT INTO #paramNames VALUES ( 3, 'emailaddress')
INSERT INTO #paramNames VALUES ( 4, 'phonenumber')
select * from #paramNames
INSERT INTO #param VALUES (1, 1, Null, Null, 'John' , Null, Null)
INSERT INTO #param VALUES (2, 2, Null, Null, 'Doo' , Null, Null)
INSERT INTO #param VALUES (3, 1, 752, 1, Null , Null, Null)
INSERT INTO #param VALUES (4, 2, 752, 2, Null , Null, Null)
INSERT INTO #param VALUES (5, 4, 752, Null, Null , 615164899, Null)
INSERT INTO #param VALUES (5, 3, 752, Null, 'me#here.com' , Null, Null)
select
a.paramParentID, b.paramName, c.paramText, c.paramINT, c.paramDate
from #param a
inner join #paramNames b on a.paramNameID = b.paramNameID
inner join #param c on a.paramChildID = c.paramID
UNION ALL
select
a.paramParentID, b.paramName, a.paramText, a.paramINT, a.paramDate
from #param a
inner join #paramNames b on a.paramNameID = b.paramNameID
WHERE paramParentID IS NOT NULL
AND paramChildID IS NULL
giving the result
paramParentID paramName paramText paramINT paramDate
752 firstname John NULL NULL
752 lastname Doo NULL NULL
752 phonenumber NULL 615164899 NULL
752 emailaddress me#here.com NULL NULL

Answer 1

I would approach this a little differently if you have performance and flexibility in mind.
USE Test;
CREATE TABLE Customers
(
CustomerID INT NOT NULL CONSTRAINT PK_Customers
PRIMARY KEY CLUSTERED IDENTITY(1,1)
, CustomerName NVARCHAR(255)
);
CREATE TABLE CustomersReceivingEmails
(
CustomerID INT NOT NULL CONSTRAINT FK_CustomerID
FOREIGN KEY REFERENCES Customers (CustomerID)
ON DELETE CASCADE ON UPDATE CASCADE
, EmailAddress NVARCHAR(255) NOT NULL
CONSTRAINT PK_CustomersReceivingEmails
PRIMARY KEY CLUSTERED (CustomerID, EmailAddress)
);
INSERT INTO Customers (CustomerName) VALUES ('Max');
INSERT INTO Customers (CustomerName) VALUES ('Mike');
INSERT INTO CustomersReceivingEmails (CustomerID, EmailAddress)
VALUES (1, 'us#them.com');
INSERT INTO CustomersReceivingEmails (CustomerID, EmailAddress)
VALUES (1, 'us#me.com');
/* ALL Customers */
SELECT * FROM Customers;
/* Only customers who wish to receive Emails, allows a given customer
to have multiple email addresses */
SELECT C.CustomerName, E.EmailAddress
FROM Customers C
INNER JOIN CustomersReceivingEmails E ON C.CustomerID = E.CustomerID
ORDER BY C.CustomerName, E.EmailAddress;
The SELECT returns rows like this:
This allows the Customers table to contain all customers regardless of their preference for emails.
The CustomersReceivingEmails table has a foreign key to Customers.CustomerID for customers who want to receive emails.

Answer 2

Your second solution is a variant of what is commonly known as Entity-Attribute-Value data model. This approach appears to be flexible. However, it essentially generates a schema within schema and is very slow to query as the number of attributes increases
If you're storing a lot of identical values, have a look at columnstore indexes. They work well in scenarios where selectivity is low (lots of rows & only a small number of distinct values)