M
Mike Fechner
Guest
You are not getting the point. If it’s stored in the DB as a character / clob, how do you want to do indexed searches on properties of the JSON object? It’s not possible, unless there is a special data type with special handling – right in the DB. Or do you still deny the existence of a real overhead when you need to go through 100.000 records (sequentially), build JSON objects from string data and compare a property from the JSON object with a value? Von: Thomas Mercer-Hursh [mailto:bounce-tamhas@community.progress.com] Gesendet: Sonntag, 15. Juni 2014 18:28 An: TU.OE.General@community.progress.com Betreff: RE: [Technical Users - OE General] json datatype RE: json datatype Reply by Thomas Mercer-Hursh I understand the use case. The only piece I am unsure about ... and mind you, it is unsure, not active opposition ... is the need for a special JSON datatype vs stuffing the JSON in a CLOB. If one sends it over the wire, one is just sending character data ... it happens to be in a format which is useful to the destination without special parsing. Here, one is in the context of paying the price of a disk read, so a little ABL overhead is minor and can't one parse a longchar into a JSON object ready for use with one line of code? So, where is the advantage? Stop receiving emails on this subject. Flag this post as spam/abuse.
Continue reading...
Continue reading...