Way to call and explain: "potentially infinite set of attributes" in databases

Question

This is a bit of a theoretical question. I would like to know how to call the principle described below, in proper computer science terms, or math terms.

Let's say we have a database in which one entity is split into two tables: main and meta. The main table is a matrix where rows are instances (for instance each row is an order), columns are attributes (for instance order id, customer name). The meta table is a key-value store of other attributes where you'll see columns for the instance id, key, and value. Visual representation of this example below.

The thing about this structure is that it allows an instance to have an infinite number of properties, because any property of an 'order' just becomes a row in the 'meta' table.

So my question is: Is there a computer science term for 'potentially infinite set of properties'? I was thinking about 'indiscrete set', but I suspect this is not the correct way to describe this.

I am experimenting with this database structure, inspired by the Wordpress database. Also building a Laravel package that supports this structure: https://packagist.org/packages/phitech/entities. I personally think this is a practical data structure. But besides that, I feel I lack some knowledge and context to what I am actually doing. I'd like to learn this and also be able to describe it. That's why my question. This is not meant to be a discussion, which wouldn't be appropriate on SE. Just curious about your knowledge about this.

Answer 1

Your "potentially infinite" (I would say: finite but unbounded) list of properties is known, depending on the programming language, as an association list, property list, dictionary, associative array, or hash. No doubt other terms are in use as well; I haven't used more than some 20-30 different languages. In mathematics, it is known as a function or mapping with a finite domain.

Your idea is known as EAV (Entity-Attribute-Value model).

It is regarded with suspicion by relational database designers: use it if your set of attributes varies strongly at runtime, or if you aren't going to need to perform complex querying on your data, but be aware of losing the advantages of database normalization (value type checking, constraint checking).