What is the proper name for this table schema?

We have a common database schema that we use for some tables in our system. Them main reason is that we are running a multi-tenant database so not all of our users require the same fields. However, I do not know what the 'proper' na开发者_JAVA技巧me for this type of schema is.

Here's an example of what one of our tables might look like:

ClientID | SurveyID | AnswerKey | AnswerVal
-------------------------------------------
1        | 1        | Fname     | Fred
1        | 1        | Lname     | Flintsone
1        | 1        | Email     | Fred@flintstone.com
1        | 2        | Fname     | Mickey
1        | 2        | Lname     | Mouse
1        | 2        | Phone     | 555-3343

We have been calling them 'Vertical tables', but I don't know if this is correct.

---

I'd probably refer to is as a Key-Value-Pair table

---

"What is the proper name for this table schema?"

Crap.

Consider what you would have to do to impose some type constraint on, say, the AnswerValue for email fields.

Consider the effort involved in enforcing possibly required "completeness" constraints requiring some specified set of fields to all be present in some survey.

Consider the effort involved in producing single rows (of which I assume that it can be known upfront which columns need to be included, because you know for which User you are working, thus you know which fields he is interested in).

Consider the effort involved in securing that there is no way for any user to retrieve or manipulate any of the fields he is not interested in.

And I'm sure there's even more ...

---

Entity-Attribute-Value

---

I'd call this a Soft-Coding database design. Sorry to be a bit abrasive, but this kind of design just smells like an anti-pattern.

---

Coincidentally after looking at this question I came across the answer in this article

Entity-Attribute-Value Table

http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/

---

Sorry, but you might want to consider normalizing your table...it can lead to maintainable code (and easier to understand). Use the power of relational tables!