I am new to databases and MySQL
in particular. Suppose I need to store flat key-value data structures in MySQL
. Each data structure has a few required fields and a number of optional fields that are not known in advance and may change frequently.
I will need to retrieve all data structures by one of the required fields and probably delete them.
So I'd like to store these data structures in a table like that: (just a copy-paste from the Internet rather than working code)
CREATE TABLE my_data_structures (
my_data_structure_id INT NOT NULL,
my_required_field1 VARCHAR NOT NULL,
my_required_field2 INT NOT NULL,
PRIMARY KEY (my_data_structure_id)
)
CREATE TABLE my_optional_fields (
my_optional_field_name VARCHAR NOT NULL,
my_optional_field_value VARCHAR NOT NULL,
FOREIGN KEY (my_data_structure_id) REFERENCES my_data_structures(my_data_structure_id)
)
Does this approach make sense ? How to define the primary key
for the second table ?
A key-value database is a type of nonrelational database that uses a simple key-value method to store data. A key-value database stores data as a collection of key-value pairs in which a key serves as a unique identifier. Both keys and values can be anything, ranging from simple objects to complex compound objects.
A key-value pair consists of two related data elements: A key, which is a constant that defines the data set (e.g., gender, color, price), and a value, which is a variable that belongs to the set (e.g., male/female, green, 100). Fully formed, a key-value pair could look like these: gender = male. color = green.
A key-value pair (KVP) is an abstract data type that includes a group of key identifiers and a set of associated values. Key-value pairs are frequently used in lookup tables, hash tables and configuration files.
On the technical side, key-value stores are commonly used for in-memory data caching to speed up applications by minimizing reads and writes to slower disk-based systems. Hazelcast is an example of a technology that provides an in-memory key-value store for fast data retrieval.
I frequently warn about the hazards of EAV (Entity–attribute–value), but I don't say it's EVIL. It's just fundamentally not relational, so using a language like SQL that is designed to store and query relational data is always going to be awkward and inefficient.
Use EAV if there's no other option, but be warned that you're obligating yourself to more work when you use EAV. Your queries will be more complex, you lose the ability for the database server to enforce constraints, and so on.
An alternative is to use some type of non-relational database, like a document store, so you can insert a set of user-defined fields as needed.
MySQL provides the JSON data type, so you have a sort of hybrid mode where you can use conventional columns with SQL data types for attributes you always need, and then JSON for dynamic attributes.
For the second table, I would recommend:
varchar
my_data_structure_id
unique
constraintThe result is something like:
CREATE TABLE my_optional_fields (
my_optional_fields_id int auto_increment primary key,
my_data_structure_id int not null,
my_optional_field_name VARCHAR(255) NOT NULL,
my_optional_field_value VARCHAR(255) NOT NULL,
FOREIGN KEY (my_data_structure_id) REFERENCES my_data_structures(my_data_structure_id)
UNIQUE (my_data_structure_id, my_optional_field_name, my_optional_field_value)
);
I am guessing that the unique constraint is on the pair. However, if you just want one field of a given name, exclude the value from the unique
constraint.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With