What are the pros and cons of different combinations of objects and arrays for data storing?

Question

From the article JavaScript 2D Array – Two Dimensional Arrays in JS, I see one way to store data is to put all properties of each element into one array:

let dataRepresentation1 = [
    ['John Doe', 20, 60, 'A'],
    ['Jane Doe', 10, 52, 'B'],
    ['Petr Chess', 5, 24, 'F'],
    ['Ling Jess', 28, 43, 'A'],
    ['Ben Liard', 16, 51, 'B']
];

I wonder how that compares to array of objects:

dataRepresentation2 = [
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    },
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    }
]

and having each property in their own array:

dataRepresentation3 = [
    [ 'John Doe', 'Jane Doe', 'Petr Chess', 'Ling Jess', 'Ben Liard' ],
    [ 20        , 10        , 5           , 28         , 16          ],
    [ 60        , 52        , 24          , 43         , 51          ],
    [ 'A'       , 'B'       , 'F'         , 'A'        , B           ]
] 

Here are my try to compare them:

Representation	1	2	3
Easy to comprehend	OK	Good	OK
Easy to compute (modify, slice, filter, etc)	Good	?	Bad
Easy to get a specific value	Good	Good	OK

Are these evaluations correct? Are there other criteria to include in? I'm mostly use JS and Python, if that matters.

See also: Array of objects vs Object of Objects

Answer 1

I would probably only use #3 for data analytic functions specifically when most of my use cases are aggregate functions on columns (Min, Max, Avg, Sum) - you could also binary search on a column; if the data is sorted on that column. The primary advantage of #3 is you don't have to extract the column you can just pass the raw array to the aggregate function.

Both #1 and #2 have the advantage that it is easy to "extract" a single record, since in most cases you will have a lot of functions that need to process a single record - hence you don't need to pass in the entire structure and an index.

#1 is more memory efficient than #2 since it doesn't repeat the keys with every record - however there is a trade off that you need to maintain the mapping of column to column index and ensure all places you access the column are updated if a column inserted or deleted from the middle of the array - so I would generally favor #2 over #1.

That said in a strongly typed OOP language, I would choose a List/Array of Objects over both #1 and #2 - since that is likely more memory efficient than both options and it also provides type safety.

Finally if I were to switch to a language like C I would choose an array of (ideally fixed size **) structs that way memory access is linear (it is not necessary to follow pointers), hence we gain the performance benefits from better cache locality.

** - Large strings may still need pointers - to avoid creating huge structures.

Answer 2

dataRepresentation1 and dataRepresentation3 are identical, you are just swapping around the indices when accessing them (data[x][y] vs data[y][x]). However dataRepresentation1 is probably better than 3 since you are keeping like objects together, but realistically doesn't make much of a difference.

dataRepresentation2 is similar to dataRepresentation1 but instead of using a numerical index in an array to a named key in an object, the only difference to both is "developer experience" where you can see at a glance what each column represents, but functionally doesn't make a difference.

All 3 are easy to comprehend, dataRepresentation2 probably being the easiest to comprehend since it is explicit in what each "column" is.

Easy to compute depends on what you are trying to do with them.

And as you already stated in easy to get values, they are all as good as each other.

Answer 3

TLDR;

In the final analysis this OP boils down to forcing coherent objects to look like RDBMS data tables so there is a 1:1 ( object K:V ) to ( DB table column ), flagrantly ignoring prudent RDBMS normalization.

---

---

This question is subtly convoluting data and information. This thought experiment reorganizes information and asks if we can guess the object members and meaning.

There is no de facto definition of what the data is: either in terms of RDBMS column headings or object Key-Value pairs. So how can we judge what is "easier" to read when we don't know what is what.

The explicit JS object notation has (requires?) an "ID", which is not a requirement for a coherent object.

The other representations fragments objects into positional-related groups vaguely resembling table-organized data; of which we are to infer what is what - hence this thread's title.

Interestingly there is no "ID" to coalesce the fragmented objects. An "ID" is not required per-se for a RDBMS table but the absence of a defined primary key (which does not have to be a GUID-like "ID") makes me think "one table to rule them all." The follow up question in the genre of object-data mashup is, "why is my database so slow?"