Comment by irrigation | Hacker News Reader

Comment by irrigation | Hacker News Reader

Parent Full thread

As someone who extensively uses pgsql and SQL Server, I don't think it's fair to say that PostgreSQL is "more advanced" because it has one particular, somewhat trendy feature. There are many critical features that pgsql either lacks (query parallelization), or came many years after SQL Server (index-only scans, true materialized views, etc).

And really json in the database is just the more modern version of xml in the database, which of course SQL Server has supported for years. The problem with xml in the database was not a fundamental one, but rather an implementation issue -- where the json model in most solutions is some variation of toss-some-structured-data-in and then work with it, the XML model of SQL Server required significant poorly documented, confusing to implement configuration to work with in any meaningful way. It really killed the feature.

Personally I still think XML is superior to JSON, but it got usurped by the architectural astronauts who kept layering noise on it to the point of being unusable.

I thought it was implied in the context, but the "more advanced" obviously meant "more advanced in terms of JSON support". Sorry if there was clarification needed.

What SQL Server 2016 will have next year seems to be more limited than what PostgreSQL 9.2 (by 2012) had. PostgreSQL at least had a native datatype ("json") to store text that syntactically validated JSON, while in SQL Server, 4 years later, you may have non-valid JSON data on a column expected to have JSON (unless you setup the validation as a constraint, which is prone to error and cannot be used in functions which expect or return JSON data anyway). Plus PostgreSQL had by 9.2 many functions to query JSON types in a very easy manner, while I don't see the same functionality coming to SQL Server 2016.

Regarding indexing, by 9.2's time you could use functional indexes to index arbitrary JSON paths (one index per path). In SQL Server you'd only be able to use computed (persisted) columns to index JSON paths, which seems to be a less elegant and less performing solution (more storage required) to the same problem.

So all in all, I honestly think that in terms of JSON support SQL Server 2016 will be less advanced than 2012's PostgreSQL 9.2, and definitely way less advanced than current's 9.4 or even more this year's 9.5. But that's, of course, only my opinion :)

json's been around for over ten years and is the default serialization format for most web frameworks. To call it trendy in the same breath as singing the praises of XML is a bit gauche.

JSON is used for persistence in a limited number of projects, and still lacks fundamental things like a validation schema or even a date type. Yes, it absolutely is "trendy", and it absolutely pales compared to XML. They both fill virtually the identical requirement, one just slowly repeating all of the mistakes of the other, as history tends to repeat itself.

JSON is an improvement overall even though there are certainly issues. It is easier to read, easier to parse, and usually fewer bytes for the same data. Validation schema can be provided by JSON Schema [1]. The lack of date type and comments is annoying, but not that big of a deal. I think parsing and reading are far more important to get right which XML didn't.

1. http://json-schema.org/

> but not that big of a deal. I think parsing and reading are far more important to get right which XML didn't.

...in your opinion, for your use cases. I think XML is eminently more readable due to the fact that it has named types and also because I never have to read the following and figure out what goes where:

    }}}}}]]}}]]}}

JSON is great for sending data to Javascript though and I'm pretty sure that's the only reason anyone is using it.

You have the same problem in XML with that amount of nesting. Then you pretty print the XML or JSON and problem solved.

Reply on news.ycombinator.com