What is a good approach in creating a non-NoSQL, relational multi-schema database?

Question

Consider a situation where the schema of a database table may change, that is, the fields, number of fields, and types of those fields may vary based on, say a client ID.

Take, for example a Users table. Typically we would represent this in a horizontal table with the following fields:

• FirstName
• LastName
• Age

However, as I mentioned, each client may have different requirements.

I was thinking that to represent a multi-schema approach to Users in a relational database like SQL Server, this would be done with two tables:

1. UsersFieldNames - {FieldNameId, ClientId, FieldName, FieldType}
2. UsersValues - {UserValueId, FieldNameId, FieldValue}

To retrieve the data (using EntityFramework DB First), I'm thinking pivot table, and the use of something like LINQ Extentions - Pivot Extensions may be useful.

I would like to know of any other approaches that would satisfy this requirement.

I'm asking this question for my own curiosity, as I recall similar conversations coming up in the past, and in relation to this question posed.

Thanks.

Answer 1

While I think a NoSQL data base would work best for this, I once tried something like this.

Have a table named something like METATABLES, like this

METATABLE = {table_name, field name}

and another,

ACTUAL_DATA ={table_name, field_name, actual_data_id, float_value, string_value, double_value, varchar_value}

in actual_data, the fields table_name and field_name would be foreign keys, pointing to METATABLES. In METATABLES you define the specific fields each client requires. the ACTUAL_DATA table holds the actual values of those fields, stored in the appropiate value field, depending on the data type (if the field value is a string, it would be stored in the string_Value field).

This approach is probably not the most efficient, though. Hope it helps.

Answer 2

I think it would be a mistake to have the schema vary. It is typically something you want to be standard.

In this case you may have users that have different attributes. In the user table you store attributes that are common across all users:

USER {id(primary key), username, first, last, DOB, etc...}

Note: Age is something that should not be stored, it should be calculated.

Then you could have a USER_ATTRIBUTE table:

{userId,key,value}

So users can have multiple attributes that are unrelated to one another without the schema changing.

Changing the schema often breaks the application.