4 ms·
I agree that array processing probably doesn't need to live in a database, but I think databases should base their foundations on arrays. In kdb you go from pr
by snidane 6y ago
I agree that array processing probably doesn't need to live in a database, but I think databases should base their foundations on arrays.
In kdb you go from primitives to arrays to tables. In SQL you go from primitives straight to tables which makes it cumbersome to do any simple one column or array ops. Such as excluding a column from a select expression.
Compare first class array support in sql vs hypothetical programmable sql
select table.* - {name, age}
from table
vs
select (
select column
from table
where column
not in ('name', 'age')
)
from table
- mamcx 6y ago> In SQL you go from primitives straight to tables This make a lot of sense. Because primitives ARE "tables", columns ARE "tables". A primitive is a relation of one column/row. This is what allow you to do: SELECT * FROM (SELECT 1)a What sql/rdbms not do it well is to exploit this very well.