21–30 of 91 posts
Then using MySQL as a nosql might work.
Interesting that he advocates MySQL. PostgreSQL can index and interact with the JSON stored in it's columns, which make it a better choice as a NoSQL replacement. http://www.postgresql.org/docs/9.4/static/datatype-json.html
The JSON datatype is only useful if you want to query on the blob, which is not the case in Wix's case.
Earlier quoted context omitted.
Does anyone have a real, globally accepted NoSQL definition yet?
Well, it used to be databases that do not do SQL. But now, that Cassandra has SQL like query language, hadoop has SQL like hive and other NoSQLs implement semi-SQL interfaces, I believe a good definition is a database that is not one of 1. ACID 2. Strongly typed table schema.
I'm going to question your knowledge of the domain immediately when your solution to a problem is to take away all of the advantages of SQL without any of the benefits that Cassandra or Redis provide. To me this is akin to saying we don't need Haskell because Java now has lambda expressions.
The main advantage of MySQL that we keep is the rock solid platform with all the know-how to operate and manage.
This is right and wrong in the same time. Not sure which more. Storing JSON as TEXT is great, but you really only query the data based on the mySQL index. What if you need to query based on the site_data? This is really not NoSQL this is just a key value store with a JSON object that is not even native type to the database, you will still need to parse back/forth. What about updating the data? You need to get the obj…
YesSQL is better than NoSQL for some problems (I happen to think many of them.)
NoSQL is better than YesSQL for some problems (I happen to think more of them than I thought a few years ago.)
I'm glad that YesSQL worked well for Wix in this case.
You don't know my workload. You don't know my requirements. It is ok to make a post saying that a specific tool is wrong for these use cases, or that you believe that many people using a tool don't need it or would be better off with a different tool..... But don't act like you know my workload.
I did an extensive survey of NoSQL databases recently and for my particular requirements Postgres ended up being the best choice. I examined MySQL too in this particular survey. Can't remember why but its JSON handling didn't meet my needs. Every time I consider alternative databases -and I've done so several times in the past ten years - I do a thorough examination and the answer always seems to come back to Postgre…
Seems like a join would allow the query planner to decide how to carry out the query.