Is your feature request related to a problem? Please describe.
At the moment the implementation we have around mods and mod values is a bit complex, and hard to maintain imho. :)
Describe the solution you'd like
A more tree like structure, where entities are simpler and relationships are of type child to parent (many to one). Eg:
A Mod has name, type and description. A mod belongs to a category
A ModValue has a parent mod, and a string value.
Many ModValues can belong to the same Mod. This means that, by default, all mods are of type multi-select. This is the most general case, with mods of type select and integer being particular cases.
An Item can have any number of mods from the category.
An Entry, or ListEntry has an Item and a list of ModValues.
Database tables:
Table
Column
DataType
Comments
mods
id
integer
primary key, autoincremented
category_id
integer
foreign key to categories (not sure about this)
name
string
unique
type
string
integer, select, multi-select
description
string
mod_values
id
integer
primary key, autoincremented
mod_id
integer
foreign key to mods
value
string
items_mods
id
integer
primary key, autoincremented
mod_id
integer
foreign key to mods
item_id
integer
foreign_key to item
entries
id
integer
primary key, autoincremented
list_id
integer
foreign key to lists
item_id
integer
foreign key to items
amount
integer
entries_mod_values
id
integer
primary key, autoincremented
entry_id
integer
foreign key to entry
mod_value_id
integer
foreign key to mod_values
This schema allows the following operation relatively easily:
Get all mods for a given category
Get all values for a given mod
Get all items for a given mod
Get all mods for a given item
At the application level (either on the frontend, or on the backend) we can:
Ensure that an item has a single value for mods of type integer.
Ensure that an item has a single value for mods of type select, and the value is among the existing mod values for that mod.
Ensure that all mod values for a given item and mod of type multi-select are among the values for that mod.
Questions:
do we want to be that strict in the toolbox ?
do we absolutely need different kinds of mod values? Can't we just have implicit mods of type multi-select?
Is your feature request related to a problem? Please describe.
At the moment the implementation we have around mods and mod values is a bit complex, and hard to maintain imho. :)
Describe the solution you'd like
A more tree like structure, where entities are simpler and relationships are of type child to parent (many to one). Eg:
Mod
has name, type and description. A mod belongs to acategory
ModValue
has a parent mod, and a string value.ModValues
can belong to the same Mod. This means that, by default, all mods are of typemulti-select
. This is the most general case, with mods of typeselect
andinteger
being particular cases.Item
can have any number of mods from the category.Entry
, orListEntry
has anItem
and a list ofModValues
.Database tables:
integer
,select
,multi-select
mods
mods
item
lists
items
entry
mod_values
This schema allows the following operation relatively easily:
At the application level (either on the frontend, or on the backend) we can:
integer
.select
, and the value is among the existing mod values for that mod.multi-select
are among the values for that mod.Questions:
multi-select
?