cancel
Showing results for 
Search instead for 
Did you mean: 

What background is best for q-sql developer?

kuentang
New Contributor

 

Recently, I came across this post on linkedin hiring for q-sql developer. The original post was:

 

 

 

 

 

>>>

 

 

Hi, new to the forum, but want to pose a question to the group. We are a trading firm in need of a kdb+ developer, specifically for q-sql. We have a few developers working on kdb+ right now, and the person we are looking for wouldn't need to be a dba or work on the q side of the platform. The feedback I have gotten is that: 1) it's very hard to find someone experienced in the q-sql language, and 2) a sql background might be the best place to start to look. Is that accurate, or is there anything the group can offer with respect to narrowing the search from "someone who has sql experience"? That seems to broad... Thanks for your help.

 

 

>>>

 

 

 

 

 

 

 

 

As far as I can see, a background in sql could  get even worse. Compare the following two queries one in sql and the other one in q:

 

 

 

 

 

in q:

 

 

 

 

 

select revenue wavg supplier.nation=`BRAZIL by order.date.year from lineitem

 

 

  where order.customer.nation.region=`AMERICA, order.date.year in 1995 1996, part.type=`STEEL

 

 

 

 

 

in sql:

 

 

 

 

 

select o_year,sum(case when nation = 'BRAZIL' then revenue else 0 end)/sum(revenue) as mkt_share

 

 

from(select year(o_orderdate) as o_year,revenue,n2.n_name as nation

 

 

  from part,supplier,lineitem,orders,customer,nation n1,nation n2,region

 

 

  where p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey

 

 

   and o_custkey = c_custkey and c_nationkey = n1.n_nationkey

 

 

   and n1.n_regionkey = r_regionkey and r_name = 'AMERICA' and s_nationkey = n2.n_nationkey

 

 

   and o_orderdate between date('1995-01-01') and date('1996-12-31') and p_type = 'STEEL')

 

 

  as all_nations group by o_year order by o_year;

 

 

 

 

 

 

 

 

There is a significant difference between sql and qsql. And people with sql background must rethink the q way which can be tough.

 

 

 

 

 

In my opinion it is more important to be able to think in array. Compare the execution times of following two q queries:

 

 

 

 

 

prx:10000000?1.0;

 

 

 

 

 

q) \t 0n{(x-y) % y}':prx

 

 

406

 

 

 

 

 

q) \t { 0n,(neg[s] + 1_x) % s:-1_x } prx

 

 

39

 

 

 

 

 

The second one is much faster because it solves the problem in a manner that is suitable for kdb+. But which people should have this background?

 

 

 

 

 

What is your opinion?

 

 

 

 

 

Kim

 

 

 

 

 

 

 

 

1 REPLY 1

sudhakar
New Contributor
Agree, an average sql expert is going to get lost in q.

I think any background is fine as long as they have the passion and commitment to invest time and effort in q/kdb.