November 10, 2017 at 2:03 pm
Comments posted to this topic are about the item Microservices in SQL Server
Best wishes,
Phil Factor
November 13, 2017 at 4:53 am
Funny... they said the same thing when they came out with support for XML in SQL Server and XML still sucks as does the great divide between front end Developers and DBAs and the database engine itself.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2017 at 5:20 am
As a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
November 13, 2017 at 5:26 am
ALZDBA - Monday, November 13, 2017 5:20 AMAs a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )
Heh.... I love those guys. And, I love the picture... The first thing I thought of when I saw that picture was "fine example of XML and JSON working together". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 13, 2017 at 8:26 am
Jeff Moden - Monday, November 13, 2017 5:26 AMALZDBA - Monday, November 13, 2017 5:20 AMAs a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )Heh.... I love those guys. And, I love the picture... The first thing I thought of when I saw that picture was "fine example of XML and JSON working together". 😉
I've not had a chance to play with JSON within SQL. That said - from what little I've seen of it, it mirrors function for function the support that was built up for XML, It was almost like someone took the XML support and ported to the JSON markup.....
That actually leads to my question for Phil: what was it that you saw that made you want to endorse the JSON support in SQL?
I'm seeing about the same level of commitment to JSON as to XML at the beginning (no support for JSON schema content through and no option to meaningfully index the JSON contents), and other than the fanboy craze for the "new" hot format (which is just reflective of a slightly different markup philosophy, but not much else over XML), I'm not seeing this as better or worse than the XML aspect. That said - I've not thoroughly kicked the tiers on it yet, so I could certainly be missing something.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 13, 2017 at 9:24 am
I can understand why developers like JSON. For passing simple payloads between services it is fine, if a little bulky.
As a recipient of JSON for uploading into a data warehouse I am far from keen. My main gripe with JSON is that I feel it tilts too far towards "avoidance of discipline" rather than "overcoming a constraint". From what I have seen I would endorse the point made by 10Gen (later Mongo Inc) that data modelling becomes more important in NOSQL not less. The JSON documents I see don't reveal any great data modelling talent.
Jeff has commented that optimising code gives greater pay back than throwing hardware at a problem. A well thought out JSON document can be passed relatively efficiently around the components of an application. The problem I see is that people try to deny the laws of physics and expect huge documents to accelerate and move at the same speed as small ones.
Perhaps we need some CosmoDB articles on SQLServerCentral to show us how it should be done?
November 13, 2017 at 12:02 pm
David.Poole - Monday, November 13, 2017 9:24 AMPerhaps we need some CosmoDB articles on SQLServerCentral to show us how it should be done?
volunteering?
November 13, 2017 at 12:12 pm
I'd be starting at the absolute beginning as I haven't touched Azure. I don't think I've touched Microsoft tech at work for over 3 years
November 13, 2017 at 12:42 pm
Matt Miller (4) - Monday, November 13, 2017 8:26 AMJeff Moden - Monday, November 13, 2017 5:26 AMALZDBA - Monday, November 13, 2017 5:20 AMAs a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )Heh.... I love those guys. And, I love the picture... The first thing I thought of when I saw that picture was "fine example of XML and JSON working together". 😉
I've not had a chance to play with JSON within SQL. That said - from what little I've seen of it, it mirrors function for function the support that was built up for XML, It was almost like someone took the XML support and ported to the JSON markup.....
That actually leads to my question for Phil: what was it that you saw that made you want to endorse the JSON support in SQL?
I'm seeing about the same level of commitment to JSON as to XML at the beginning (no support for JSON schema content through and no option to meaningfully index the JSON contents), and other than the fanboy craze for the "new" hot format (which is just reflective of a slightly different markup philosophy, but not much else over XML), I'm not seeing this as better or worse than the XML aspect. That said - I've not thoroughly kicked the tiers on it yet, so I could certainly be missing something.
JSON is generally more readable than XML, particularly SOAP. In general JSON is just a formatted hash table, unlike XML it's not trying to store any meta data about the format of the data. It might be the FOTM but it's better than XML and that's why it's being used.
November 13, 2017 at 12:49 pm
@matt-2 miller
What particularly was it that I saw that made me want to endorse the JSON support in SQL?
It is the performance primarily. It is way faster than XML. See https://blog.bertwagner.com/one-sql-cheat-code-for-amazingly-fast-json-queries-1c2402b4b0d2 and http://codingsight.com/sql-server-2016-json-vs-xml-performance-comparison-part-6/ . Try it out yourself. Please don’t be jaundiced by your experience of xml. The JSON support in SQL Server 2016, and improved in 2017, is very useful indeed.
Best wishes,
Phil Factor
November 13, 2017 at 1:08 pm
ZZartin - Monday, November 13, 2017 12:42 PMMatt Miller (4) - Monday, November 13, 2017 8:26 AMJeff Moden - Monday, November 13, 2017 5:26 AMALZDBA - Monday, November 13, 2017 5:20 AMAs a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )Heh.... I love those guys. And, I love the picture... The first thing I thought of when I saw that picture was "fine example of XML and JSON working together". 😉
I've not had a chance to play with JSON within SQL. That said - from what little I've seen of it, it mirrors function for function the support that was built up for XML, It was almost like someone took the XML support and ported to the JSON markup.....
That actually leads to my question for Phil: what was it that you saw that made you want to endorse the JSON support in SQL?
I'm seeing about the same level of commitment to JSON as to XML at the beginning (no support for JSON schema content through and no option to meaningfully index the JSON contents), and other than the fanboy craze for the "new" hot format (which is just reflective of a slightly different markup philosophy, but not much else over XML), I'm not seeing this as better or worse than the XML aspect. That said - I've not thoroughly kicked the tiers on it yet, so I could certainly be missing something.
JSON is generally more readable than XML, particularly SOAP. In general JSON is just a formatted hash table, unlike XML it's not trying to store any meta data about the format of the data. It might be the FOTM but it's better than XML and that's why it's being used.
Thanks!
I do understand the difference between the two messaging models (although I find readability is usually in the eye of the beholder). As a former developer I can see how it is incrementally easier to consume than XML (although most modern languages make it easy to do either). The two weren't built with the same use cases in mind, so I'm not surprised that one is more succinct than the other.
That said - my question wasn't around the differences between JSON and XML, It's more around how this supposedly simple switch all of a sudden removes all needs for devs to not have to worry about relations, but that the data will still always land just find with no grey hairs or headaches on the modeling end. I've heard a lot of tall tales as the newest technology promises to obliterate the grand divide: Phil seems to think this solves it, so I was curious how.
Edit: corrected feasibility to reability 😉
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 13, 2017 at 1:19 pm
There need be no mismatch between the object-oriented world and the relational because we, as data people, can now do all the worrying about the translation in both directions, and obsess about both the data security and integrity.
So were talking about that "impudence mismatch" thingy that developers keep complaining about?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 13, 2017 at 1:27 pm
Matt Miller (4) - Monday, November 13, 2017 1:08 PMZZartin - Monday, November 13, 2017 12:42 PMMatt Miller (4) - Monday, November 13, 2017 8:26 AMJeff Moden - Monday, November 13, 2017 5:26 AMALZDBA - Monday, November 13, 2017 5:20 AMAs a picture says more than 1000 words: Statler & Waldorf ( and I hope everybody still knows the duo )Heh.... I love those guys. And, I love the picture... The first thing I thought of when I saw that picture was "fine example of XML and JSON working together". 😉
I've not had a chance to play with JSON within SQL. That said - from what little I've seen of it, it mirrors function for function the support that was built up for XML, It was almost like someone took the XML support and ported to the JSON markup.....
That actually leads to my question for Phil: what was it that you saw that made you want to endorse the JSON support in SQL?
I'm seeing about the same level of commitment to JSON as to XML at the beginning (no support for JSON schema content through and no option to meaningfully index the JSON contents), and other than the fanboy craze for the "new" hot format (which is just reflective of a slightly different markup philosophy, but not much else over XML), I'm not seeing this as better or worse than the XML aspect. That said - I've not thoroughly kicked the tiers on it yet, so I could certainly be missing something.
JSON is generally more readable than XML, particularly SOAP. In general JSON is just a formatted hash table, unlike XML it's not trying to store any meta data about the format of the data. It might be the FOTM but it's better than XML and that's why it's being used.
Thanks!
I do understand the difference between the two messaging models (although I find readability is usually in the eye of the beholder). As a former developer I can see how it is incrementally easier to consume than XML (although most modern languages make it easy to do either). The two weren't built with the same use cases in mind, so I'm not surprised that one is more succinct than the other.
That said - my question wasn't around the differences between JSON and XML, It's more around how this supposedly simple switch all of a sudden removes all needs for devs to not have to worry about relations, but that the data will still always land just find with no grey hairs or headaches on the modeling end. I've heard a lot of tall tales as the newest technology promises to obliterate the grand divide: Phil seems to think this solves it, so I was curious how.
Edit: corrected feasibility to reability 😉
I can't speak to the long term viability of JSON vs XML and yes it certainly is not a perfect format. That said the use case is the same, both are designed as a plain text format for structured data and in that regard I've never found myself looking at a JSON solution and saying "damn I really wish this was XML"
November 13, 2017 at 2:49 pm
I'll say that I find JSON easier to read, though once it gets complex, both of them are hard formats to work with. Haivng SQL Server work with this can make it easier for serializing/deserializing stuff from a developer oriented format to a relational one. I don't think that this removes any need for developers to map things, but working with JSON seems easier than XML.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply
