These are chat archives for cltk/cltk_api

30th
Nov 2015
Luke Hollis
@lukehollis
Nov 30 2015 00:28 UTC
Yeah, that sounds like a really good idea
I was thinking about postgres maybe replacing Mongo due to its native json datatype?
But, I mean, meteor still uses it--segetes does fine on it for onw
Luke Hollis
@lukehollis
Nov 30 2015 00:35 UTC
Seems like building with postgres might be a little bit of having our cake and eating it too?
Kyle P. Johnson
@kylepjohnson
Nov 30 2015 02:34 UTC
I have not looked into storing JSON with Postgres, but this is compelling.
For the first iteration of the frontend, @lukehollis , do you need a db? (Such as for user, configs, etc.)
Rob Jenson
@ferthalangur
Nov 30 2015 08:11 UTC
Keep in mind 2 things about that article: 1 it is written, and the benchmarks are run, by a company who makes their money converting people to their flavor of PostgresSQL;
Rob Jenson
@ferthalangur
Nov 30 2015 08:19 UTC
2: Based on that article, and I tend to agree with that part, NoSQL databases came into existence and became popular in part because modeling data onto structured databases has a high learning curve to do it right, has a lot of developer overhead to do it well, and often required the cooperation of other professionals (e.g. DBAs) to make it happen. This interfered with the goals of agile software development (little A and big A), so NoSQL became very sexy.
We don't use PostgresSQL at CHS because we are comfortable with MySQL. Each has their advantages. At the end of the day
Rob Jenson
@ferthalangur
Nov 30 2015 08:32 UTC
You have to ask what you are trying to accomplish right now. It might be optimal, in terms of resources available, to build at the relatively unstructured level now (i.e. use MongoDB) with an eye towards an optimizing filter later that can generate SQL database schemas and procedures for storing, indexing and retrieving the data from a more efficient database engine (but don't put all your eggs in the Postgres basket ... Abstract away from what the backend database engine is).
Rob Jenson
@ferthalangur
Nov 30 2015 11:40 UTC
The other thing to consider, if your JSON can handle it, is using JSONB in a PostgresSQL database. You get much more efficient retrieval.
Rob Jenson
@ferthalangur
Nov 30 2015 11:46 UTC
Ahhhh ... they have added JSON support to MySQL 5.7, which will take a while to get real production acceptance, but it is an option.

Conclusion
One of the big reasons that people are interested in JSON support in databases is that they want to use fewer types of databases. The modern technology stack is beginning to introduce significant sprawl as people use different databases in particular areas, taking advantage of their strengths to gain efficiency. However, this polyglot persistence increases the technology surface area enough that it can become quite difficult to monitor, manage, develop, and operate such a diverse set of databases.

One potential answer to this problem is to continue using work horses such as MySQL and Postgres, replacing specialized JSON native databases with the new JSON functionality. For the record, MongoDB is not the only JSON native database. There are many databases, including RethinkDB, that deal with JSON natively.

A big difference between the JSON support in MySQL, Postgres, and MongoDB is that in MongoDB, this is the native transport across the wire as well. JSON is native end to end in this database, whereas in other databases it is typically shoehorned into row and column storage in the client and on the wire, as well as the programming API.

Still, keeping technology diversity down can be a big enough reason to continue using the reliable and trusted databases of yore.```

From: https://www.vividcortex.com/blog/2015/06/02/json-support-postgres-mysql-mongodb-sql-server/

eww ... not the look I intended. :)