M
Marian Edu
Guest
*much* better like in this will happen anyway behind the scene or? if there is no index to support a query all records will be read anyway, if a field contains json/xml someone will have to serialize/deserialize the damn data... it can be deserialization on read while data is stored in document format or serialization on read proven they come up with a better storage option, or can just de-normalize the darn thing and keep it in original format and also in a more appropriate storage format to be used in queries. if you want to skip that full table read the only way imho is to start adding indexes on that json but given you have hundreds of interfaces are you going to create that many indexes in one table (specifically one that seems to get a considerable amount of inserts)? guess you're not letting this table to build like a history table... if you need that then go with a 'staging' area, process data out of it and keep the history in some other place(s). On 06/15/2014 09:09 PM, jmls wrote: From: jmls Post: Re: json datatype Posted in: OpenEdge General Link: http://community.progress.com/technicalusers/f/26/p/10765/40340.aspx#40340 all I can say is that thousands of developers have a use-case for using json in databases - even PSC's latest acquisition, Modulus, uses MongoDB There are several cases where I have a need for json-type data : for example, interface files from external system may have some common fields like agentid, name, address, balance, but often have non-common fields so, at the moment I create a table with agentid, name, address and balance, but use a "data" clob field to store a json representation of the rest of the data - rather than creating a table for each interface (we have hundreds) Now, I have a need to loop through some of this data, and find only records with a certain key-value pair (which may or may not be several levels deep). The only way of doing that , is by reading each record, converting to json , and checking if the resultant json object has("foo") It would be *much* better to go for each inputData no-lock where InputData.data has "foo= bar" instead of reading all the bloody records. Julian On 15 June 2014 18:50, Thomas Mercer-Hursh wrote: RE: json datatype Reply by Thomas Mercer-Hursh OK, Julian, that is the first indication I have seen of an actual benefit. Now, to convince PSC development, what is the use case?The use case I get for stuffing JSON into a DB is things like preserving context across sessions.I can see wanting to index that by session id and the like, maybe a timeout value for when to preserve it, etc., but I would put those in separate fields.What are you doing with these JSON objects that you would want to retrieve on key-value pairs?Seems to me that implementing such a search feature would actually involve greater difficulty than allowing word search on a CLOB.Couldn't one accomplish this with word index? Mike, you are right, I am not getting the point.I understand use cases for putting JSON data into a database for things like caching it across passes on an AppServrer, but no, I don't know what the use case is for 100,000 of them and wanting to search across it.If one is storing a large amount of data and wanting index capabilities, why would one not put the data into regular fields? I am not against you, just playing Doubting Thomas in making you present an actual use case like development would need before considering such a thing. Stop receiving emails on this subject. Flag this post as spam/abuse. -- m.edu keep it simple http://www.ganimede.ro http://ro.linkedin.com/in/marianedu medu@ganimede.ro mobile: +40 740 036 212 skype: marian.edu
Continue reading...
Continue reading...
