I was going through some past questions for inserting json data into a postgresql table and learnt about JSONB and JSONL. I couldn't understand the difference between the both as both looks same as a list of json data i.e.
[{"a":"b","c":"d"},{"a1":"b1","c1":"d1"}]
Related
Now I'm working with GraphQL and postgresql as the database.
As you know, we can easily map data to schemas with GraphQL.
If I just use a simple join table query, we need to process the data to fit the output like graphql schema, but if I do the query using json format, the query will be very hard to read.
My question is, when should we use json format, and when should we do a simple table join? Is there any particular concern if we use json format or simple join table? and how does the performance compare between the two?
I have a sharded table with one pk column and a text column. The text column holds an object in json format. I want to enable ad hoc business analytics by using drill or presto.
Just experimented with both but i am unable to figure out how to parse the json and access its fields in a query.
For drill i tried convert_from(features,'JSON') and for presto i tried json_parse(features). Both seem to convert column text to JSON as a simple select but i cannot access object fields in the same query.
Performance is important so need to avoid io, open to options requiring development effort or hardware scaling.
I was able to analyze json column in presto by using json_extract_scalar on output of json_parse ex. json_extract_scalar(json_parse(features),'$.r_id'). This returns me a string which i can cast to required data type.
I'm working on a website which has a database table with more than 100 fields.
The problem is when my records number get very much (like more than 10000) the speed of response gets very much and actually doesn't return any answer.
Now i want to optimize this table.
My question is: Can we use json type for fields to reduce the number of columns?
my limitation is that i want to search, change and maybe remove that specific data which is stored in json.
PS: i read this qustion : Storing JSON in database vs. having a new column for each key, but that was asked in 2013 and as we know in MuSQL 5.7 json field type is added.
tnx for any guide...
First of all having table with 100 columns may suggest you should rethink your architecture before proceeding. Otherwise it will only become more and more pain in later stages.
May be you are storing data as seperate columns which can be broken down to be stored as seperate rows.
I think the sql query you are writing is like (select * ... ) where you may be fetching extra columns than you may require. You may specify the columns you require. It will definitely speed up the api response.
In my personal view storing active data in json inside sql is not useful. Json should be used as last resort for the meta data which does not mutate or needs not to be searched.
Please make your question more descriptive about the schema of your database and query you are making for api.
Does json usually have enclosing quotation marks when stored in a database field?
Which of the following would be correct for the json column?
`json`
'{"Color": "Red"}'
{"Color": "Red"}
My assumption would be the second, but just wanted to make sure that's correct. And if so, why?
As of MySQL 5.7.8, MySQL supports a native JSON data type
If you use earlier version and store it as text, store it without the enclosing quotation marks.
While it is possible to store the data as you suggest, it would be better to store the data in a table named json with field color then insert two records, each containing the value 'red'.
It's more work now, because it involves deconstructing and reconstructing the JSON, but it saves work later if you need to serve the data in some format other than JSON, then you won't need to reformat all of the data in your database.
I'm going to store records with arbitrary fields, and the custom ones will automatically go into a separate serialized field. I don't care that they're not searchable nor sortable.
I've chosen the JSON serialization format. What is the best column data type, provided I don't have the new json type?
The underlying data type in 9.2 is TEXT, so you should be able to use that - see http://michael.otacoo.com/postgresql-2/postgres-9-2-highlight-json-data-type/