Hacker News Reader

Comment by Jorge1o1 | Hacker News Reader

As a daily user of kdb+/q, I can say that at least for me, it's one of the "best feeling" and most ergonomic tools i've ever used.

I can actually query and understand tables in a very fast REPL in a way that would require 20-30 lines of SQL, nested subqueries, etc.

Even things like the way "left joins" work in KDB feels more natural than left joins in other SQL databases. https://code.kx.com/q/ref/lj/

View on HN

I second that. It feels like an abacus after a while

Interesting. This syntax reminds me a bit of the R package data.table's terseness for joins:

  B[A, on="x"] # A left join B
  B[A] # same, assuming x is the key column on both, like K's lj [x;y]
  A[B, on=.(x, y<=foo)] # right non-equi join

That's because kdb tables are much more similar to R dataframes (ordered maps of vectors), rather than to relational algebra used in RDBMS/SQL (logically sets of rows). That's for in-memory only (RDB), ignoring historical data (HDB) and persistence since kdb is a real database.

  // kdb+/q
  t: ([] sym:`AAPL`IBM`GOOG; price: 139.09 124.23 948.82; vol: 123456 98765 54321)

  # R
  df <- data.frame(sym=c("AAPL", "IBM", "GOOG"), price=c(139.09, 124.23, 948.82), vol=c(123456, 98765, 54321))

Reply on news.ycombinator.com