Possible to have a table with variable columns?

Question

It might be a stupid question, but here goes:

Is it possible to make a dynamic table that's able to contain rows with variable number of columns and custom column names?

I have glanced over EAV-modelling, but it seems heavy. A real life example could be this:

Let's say I have a register with customers. But each customer might have different information to be entered. And depending on what you want to enter, it should be reflected in the database. (I.E. every customer has different columns)

Is this impossible/probable?

Update:

The standard approach (i.e. having a table with all needed columns and saving information only into columns that make sense for a particular customer while setting the remaining ones to NULL) doesn't work for me because what I want can't use 'fixed' column names. Example one customer might want CVR-number and another might want their phonenumber as a reference number. And a third might want some completely different information. So to avoid having a table containing 500 columns, I have now thought of making an extra table containing rows of column-data. Like so: Id, Name, Value, CustomerId. So when I want information for a customer, all I have to do is to iterate through this table with a specific customer Id.

my own edit!:

Sorry for troubling you with this simple SQL-issue! :-) Have a nice day...

Answer 1

You could model this as a one-to-many relationship between a Customer and a CustomerAttributes table. Something like:

**Customer table**
CustomerId
LastName
FirstName
...

**CustomerAttributes table**
CustomerId
AttributeName
AttributeValue

Answer 2

This is not possible in Sql-Server. As Marco says, you can store each customer's data in xml.

If all the columns are known ahead of time and some customers use one set and other customers use a different set, then sub-tables with each set of columns is the normal approach.

If the columns are not known ahead of time, then how would the data even be used? No code or reports could refer to it. Perhaps it should be stored unstructured in a general purpose 'Notes' field.