Microservices in SQL Server

  • Comments posted to this topic are about the item Microservices in SQL Server

    Best wishes,
    Phil Factor

  • 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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • 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

  • ALZDBA - Monday, November 13, 2017 5:20 AM

    As 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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Monday, November 13, 2017 5:26 AM

    ALZDBA - Monday, November 13, 2017 5:20 AM

    As 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?

  • 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?

  • David.Poole - Monday, November 13, 2017 9:24 AM

    Perhaps we need some CosmoDB articles on SQLServerCentral to show us how it should be done?

    volunteering?

  • 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

  • Matt Miller (4) - Monday, November 13, 2017 8:26 AM

    Jeff Moden - Monday, November 13, 2017 5:26 AM

    ALZDBA - Monday, November 13, 2017 5:20 AM

    As 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.

  • @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

  • @steve-2 jones

    I am due to be writing some Mongo and Azure Cosmos DB articles, concentrating on the performance of data aggregation. Maybe I’ll do one for SSC.

    Best wishes,
    Phil Factor

  • ZZartin - Monday, November 13, 2017 12:42 PM

    Matt Miller (4) - Monday, November 13, 2017 8:26 AM

    Jeff Moden - Monday, November 13, 2017 5:26 AM

    ALZDBA - Monday, November 13, 2017 5:20 AM

    As 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?

  • 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

  • Matt Miller (4) - Monday, November 13, 2017 1:08 PM

    ZZartin - Monday, November 13, 2017 12:42 PM

    Matt Miller (4) - Monday, November 13, 2017 8:26 AM

    Jeff Moden - Monday, November 13, 2017 5:26 AM

    ALZDBA - Monday, November 13, 2017 5:20 AM

    As 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"

  • 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