I'd go with option 2 (jsonb), as it's likely already well supported by your
applications, while the other approaches will require a good bit of
customization. JSONB can be indexed, so performance should be on par with
"traditional" tables.
Cheers,
Greg
The relational purists will gave their concerns, but especially given what
you described about your performance and volumetrics, there is a reason why
JSON(b) is a thing. For type checking, and more, I've had success a
multi-key approach so that one entry might comprise:
- A "name"
- A "type"
- A
On 2024-09-10 12:08:14 +0500, Muhammad Usman Khan wrote:
> There is not a properly defined solution but you can try the
> Entity-Attribute-Value (EAV) Model. This is an alternative approach, where a
> separate table is used to store custom fields as attributes for each record.
> New fields can be a
Hi,
There is not a properly defined solution but you can try the
Entity-Attribute-Value (EAV) Model. This is an alternative approach, where
a separate table is used to store custom fields as attributes for each
record. New fields can be added without altering the schema. There will be
no need for D
I’m looking for input on a database design question.
Suppose you have an application that allows the user to add some kind of field
to the application („custom fields“, „user defined fields“, „extended fields“,
…), which could be of different types (eg string, int, bool, date, array of
, …), a
