12 ms·

It all depends on access pattern. Do you tend to select entire rows? Use a row-oriented DB. Do you tend to select entire columns? A column-oriented database mig

by tormeh 5y ago

It all depends on access pattern. Do you tend to select entire rows? Use a row-oriented DB. Do you tend to select entire columns? A column-oriented database might be for you. That's it, really. None of the designs are superior, afaik.

moonchild 5y ago
You might be selecting entire rows, but you are probably not selecting all of the rows, and your selection criteria probably do not depend on all of the columns.
- WJW 5y ago
  Yeah, row-oriented is good for WHERE queries and column-oriented is good for SUM (or other aggregation) queries.
hoosieree 5y ago
Just to add, because J is an array-oriented language, it makes some kinds of column-oriented access patterns easier. For example, it's trivial to sort one array by the values of another array: x /: y To me, it's much easier to read than the equivalent in NumPy: x[np.argsort(y)] Or get pairs of (unique value; count) from an array using the key operator (/.): (~.;#)/.~ y Column db's make sense for array-oriented languages, because there's much less of a mismatch compared to OOP with relational.
- legalcorrection 5y ago
  All of that syntax is awful. Why not just x.sortBy(y) ? Did all of the advances in software legibility fail to make their way to the modern scientific computing world?
  - moonchild 5y ago
    https://www.jsoftware.com/papers/tot.htm https://www.jsoftware.com/papers/tot.htm
  - avmich 5y ago
    Hyperbolically, because you don't write math with variables in camel case. J traces its roots from a notation for math, used on whiteboards. That awful syntax you see - it's the same as in some formulas in, say, general relativity, only J is Turing complete and not a Turing tarpit. When you work on a formula, in case of J you have ability to execute it, and if you see it's wrong you can update the formula and try again. This could also be done in other languages, but in J (I mean, APL family of languages) it's more focused. In defense of J, I had a professional example of a problem which wasn't clearly specified, which needed some experimentation - that took, if I remember correctly, some 45 minutes of attempts in J, and then the prototype was re-written in C#, when if was already producing desired outcomes. Rewriting took somewhat longer.

by tormeh 5y ago

moonchild 5y ago

You might be selecting entire rows, but you are probably not selecting all of the rows, and your selection criteria probably do not depend on all of the columns.

WJW 5y ago
Yeah, row-oriented is good for WHERE queries and column-oriented is good for SUM (or other aggregation) queries.

hoosieree 5y ago

Just to add, because J is an array-oriented language, it makes some kinds of column-oriented access patterns easier. For example, it's trivial to sort one array by the values of another array: x /: y To me, it's much easier to read than the equivalent in NumPy: x[np.argsort(y)] Or get pairs of (unique value; count) from an array using the key operator (/.): (~.;#)/.~ y Column db's make sense for array-oriented languages, because there's much less of a mismatch compared to OOP with relational.

legalcorrection 5y ago
All of that syntax is awful. Why not just x.sortBy(y) ? Did all of the advances in software legibility fail to make their way to the modern scientific computing world?
- moonchild 5y ago
  https://www.jsoftware.com/papers/tot.htm https://www.jsoftware.com/papers/tot.htm
- avmich 5y ago
  Hyperbolically, because you don't write math with variables in camel case. J traces its roots from a notation for math, used on whiteboards. That awful syntax you see - it's the same as in some formulas in, say, general relativity, only J is Turing complete and not a Turing tarpit. When you work on a formula, in case of J you have ability to execute it, and if you see it's wrong you can update the formula and try again. This could also be done in other languages, but in J (I mean, APL family of languages) it's more focused. In defense of J, I had a professional example of a problem which wasn't clearly specified, which needed some experimentation - that took, if I remember correctly, some 45 minutes of attempts in J, and then the prototype was re-written in C#, when if was already producing desired outcomes. Rewriting took somewhat longer.