Storing layered objects in a grid - database

Question

Let's say I have a canvas where there are various objects I can add in, such as a/an:
Drawing
Image
Chart
Note
Table
For each object I need to store the dimensions and the layer order, for example something like this:
ObjectID
LayerIndex
Dimensions ((x1, y1), (x2, y2))
Each of the objects have vastly different properties and so are stored in different tables (or classes or whatever). Would it be possible to store this into a relational database, and if so, how could it be done? In JSON it would be something like this:
// LayerIndex is the ArrayIndex
// No need to store ObjectID, since the object is stored within the array itself
Layers = [
{Type: Drawing, Props: <DrawingPropertyObj>, Dimensions: [(1,2), (3,4)]},
{Type: Chart, Props: <ChartPropertyObj>, Dimensions: [(3,4), (10,4)]},
{Type: Table, Props: <TablePropertyObj>, Dimensions: [(10,20), (30,44)]},
...
]
The one option I thought of is storing a FK to each table, but in that case, I could potentially join this to N different tables for each object type, so if there are 100 object types, ...

Answer 1

A "strict" relational database doesn't suit this task well because you're left with a choice of:
Different tables for each object type with a columns for each attribute that applies to that particular object type
A single table for all object types, with columns for each attribute, most of which aren't used for any given object type
A child table, one row for each attribute
Before moving on to a good general solution., let's discuss these:
1. Different tables for each object type
This is a non-starter. The problems are:
high maintenance cost: you must create a new table every time you add a new object type to your app
painful queries: you must join to every table, either horizontally - every table joined into one enormously long row, or vertically in a series unioned joins, leading to a sparse array (see option 2)
2. A single table for all object types
Although you're dealing with a sparse array, if most object types use most of the attributes (ie it's not that sparse), this is a good option. However, if the number of different attributes across your domain is high, and/or most attributes aren't used by all types, you have to add columns when introducing a new type, which although better than adding tables, still requires a schema change for a new type = high maintenance
3. A child table
This is the classic approach, but the worse to work with, because you either have to run a separate query to collect all the attributes for each object (slow, high maintenance), or write separate queries for each object type, joining to the child table once for each attribute to flatten out the many rows into one row for each object, effectively resulting in option 1, but with an even higher maintenance cost writing the queries
None of those are great options. What you want is:
One row per object
Simple queries
Simple schema
Low maintenance
A document database, such as Elasticsearch gives you all of this out of the box, but you can achieve the same effect with a relational database by relaxing "strictness" and saving the whole object as json in a single column:
create table object (
id int, -- typically auto incrementing
-- FK to parent - see below
json text -- store object as json
);
BTW, postgres would be a good choice, because it has native support for json via the json datatype.
I have used this several times in my career, always successfully. I added a column for the object class type (in a java context):
create table object (
id int,
-- FK to parent - see below
class_name text,
json text
);
and used a json library to deserialize the json using the specified class into an object of that class. Whatever language you're using will have a way of achieving this idea.
As for the hierarchy, a relational database does this well. From the canvas:
create table canvas (
id int,
-- various attributes
);
If objects are not reused:
create table object (
id int,
canvas_id int not null references canvas,
class_name text,
json text,
layer int not null
);
If objects are reused:
If objects are not reused:
create table object (
id int,
class_name text,
json text
);
create table canvas_object (
canvas_id int not null references canvas,
object_id int not null references object,
layer int not null
);

Answer 2

You have many options as shown below.
There is not much difference in which one you pick, but I would avoid the multi-table design which is the one you said. An object type with 100 properties would be scattered in 101 tables for no gain. 101 disk page accesses for each object type being read. That's unnecessary (if those pages are cached then this problem would be lesser than otherwise but is still waste).
Even dual table is not really necessary if you don't wish to filter things like 'all objects with color=red', but I guess performance is not so urgent to reach to this point, other things matters more, or other bottlenecks have more influence in performance, so pick the one of the no-more-than-dual-table that fits best for you.
Single table - flexible schema per object type
objlayerindex
type
props
x0
y0
x1
y1
0
drawing
{color:#00FF00,background-color:#00FFFF}
1
2
3
4
1
chart
{title:2021_sales,values:[[0,0],[3,4]]}
11
22
33
44
in props the keys are used for flexibility, different objects of the same type may have different keys, for example a chart without subtitle can omit this key.
Single table - fixed schema per object type
objlayerindex
type
props
x0
y0
x1
y1
0
drawing
#00FF00,#00FFFF
1
2
3
4
1
chart
2021_sales,"[[0,0],[3,4]]"
11
22
33
44
this schema is fixed - drawing always has color+backgroundcolor; chart always have title+values; etc - less space used but changing schema involves some work on already existing data.
Dual table
Main
objlayerindex
type
x0
y0
x1
y1
0
drawing
1
2
3
4
1
chart
11
22
33
44
Properties
objlayerindex
propertyname
propertyvalue
0
color
#00FF00
0
background-color
#00FFFF
1
title
2021_sales
1
values
[[0,0],[3,4]]
here we assume that property ordering is not important. If it is, an extra column propertyindex would be needed. For those who love normalization, it is possible also to take propertyname out of this table to a propertykey-propertydescription and reference it by its propertykey.
Multi table
Main
objlayerindex
type
x0
y0
x1
y1
0
drawing
1
2
3
4
1
chart
11
22
33
44
Color
objlayerindex
colorcode
0
#00FF00
Background-Color
objlayerindex
colorcode
0
#00FFFF
Title
objlayerindex
title
1
2021_sales
Values
objilayerindex
chart
1
[[0,0],[3,4]]
Specifically this kind of data can be normalized one extra level:
Values
objlayerindex
datapoint
x
y
1
0
0
0
1
1
3
4
You can also use non-relational formats.
Document (Json) Store
[
{type:drawing,props:{color:#00FF0,background-color:#00FF0},position:[1,2,3,4]},
{type:chart,props:{title:2021_sales,values:[[0,0],[3,4]]},position:[11,22,33,44]}
]
we are citing here because it is a popular and simple format, but different encodings can be used instead of JSON (CSV, protocolbuffers, avro, etc)