Content-Disposition: inlineHello,
Will `symbol scale for BLOB type?
Regards,
Yuva
no, that’ll end in tearssymbols are meant for short identifiers that occur often like stocksymbols, currency identifiersuse lists of bytessame way as strings are lists of charOn May 9, 2:21?pm, “Yuvaraj Athur Raghuvir” <yuvaraj…>wrote:> Hello,>> Will `symbol scale for BLOB type?>> Regards,> Yuva</yuvaraj…>
[sorry, on this machine I do not have q to experiment; so I am just putting down my thoughts to understand q better]
- For blob does this meant that I do the following?
SQL) CREATE TABLE EMP(ID integer not null primary key, NAME varchar(80) not null, ADDRESS varchar(200) not null, DESCRIPTION BLOB)
q) EMP:([ID:`int$()]name:`symbol$();address:`string$();description:`enlist`byte$()); \guessing on the representation of casting verbs
- In general, at what cutoff point does the delight turns into tears?
So, for varchar(20) I guess symbol is good.
For varchar(200)? For varchar (2000)? varchar(200000000)?
So, I would imagine that the char to q data type mapping will involve intervals of optimal performance of the data types of q. Is there any such (empirical) mapping available?
Thanks
~Yuva
p.s: I so far understand that q is excellent for analytics with small-/medium- size data types. The directions I am exploring are q as a general purpose DB. Maybe my direction of inquiry is not suited to the design goals of q. Is that so?
- as you’re calling the field DESCRIPTION then presumably it’sactually just a large variable length char string rather thannecessarily a list of bytesanyway, your schema is almost there:EMP:([ID:
int$()] name:symbol$(); address:(); description:() )the nested columns will get their type from the first insertq)u:(a:int$();s:())q)u insert (88 99;(“this”;“and that”))0 1q)meta uc| t f a-| -----a| is| Cq)ua s-------------88 "this"99 "and that"q)v:(a:int$();b:())q)v insert (88 99;(0x12121212;0x3434343434344))0 1q)meta vc| t f a-| -----a| ib| Xq)va b-------------------88 0x1212121299 0x03434343434344q)2) it’s not a cutoff point like that. Symbols are immutable symbolsthat have to be loaded at startupso they’re fine for something like stock symbols, currency symbols etcthey should not be used for columns with values that just grow andgrow or you’ll end up with a sym list hundreds of millions long, withmost of them only ever used once.so the rule would be something like:use symbols if the values occur more than once, and if they come froma comparatively small setdon’t use them if that set of values is continually growing2008/5/11 Yuvaraj Athur Raghuvir <yuvaraj.a.r>:> [sorry, on this machine I do not have q to experiment; so I am just putting> down my thoughts to understand q better]>> 1) For blob does this meant that I do the following?>> SQL) CREATE TABLE EMP(ID integer not null primary key, NAME varchar(80) not> null, ADDRESS varchar(200) not null, DESCRIPTION BLOB)> q)> EMP:([ID:int$()]name:symbol$();address:string$();description:enlistbyte$());> \guessing on the representation of casting verbs>> 2) In general, at what cutoff point does the delight turns into tears?> So, for varchar(20) I guess symbol is good.> For varchar(200)? For varchar (2000)? varchar(200000000)?>> So, I would imagine that the char to q data type mapping will involve> intervals of optimal performance of the data types of q. Is there any such> (empirical) mapping available?>> Thanks> ~Yuva>> p.s: I so far understand that q is excellent for analytics with> small-/medium- size data types. The directions I am exploring are q as a> general purpose DB. Maybe my direction of inquiry is not suited to the> design goals of q. Is that so?>>> On Fri, May 9, 2008 at 10:34 PM, simon <simon.garland> wrote:>>>> no, that'll end in tears>> symbols are meant for short identifiers that occur often like stock>> symbols, currency identifiers>>>> use lists of bytes>> same way as strings are lists of char>>>>>> On May 9, 2:21 pm, "Yuvaraj Athur Raghuvir" <yuvaraj....>>> wrote:>> > Hello,>> >>> > Willsymbol scale for BLOB type?>> >>> > Regards,>> > Yuva>>>>> >></yuvaraj…></simon.garland></yuvaraj.a.r>