Are the posted questions getting worse?

  • Stefan Krzywicki (3/11/2013)


    wolfkillj (3/11/2013)


    Jeff Moden (3/10/2013)


    Stefan Krzywicki (3/9/2013)


    Jeff Moden (3/8/2013)


    Matt Miller (#4) (3/8/2013)


    Jeff Moden (3/7/2013)


    Revenant (3/4/2013)


    Evil Kraig F (3/4/2013)


    Revenant (3/4/2013)


    I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.

    Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.

    It was not meant at you, Craig. I have been in that situation and I know how it feels.

    I feel the same way... I just can't understand why anyone would actually use XML. πŸ˜‰

    Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.

    Kind of like any other tool.

    I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.

    It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.

    Since you're able to directly query XML, as well, I'm not sure that's an advantage over XML. Based on what you said about JSON taking only 2/3rds the space of XML, I'll say they're headed in the right direction but it's still bloated compared to more conventional means.

    I don't really have a dog in the XML/JSON fight, and I know very little about JSON, but our app developers seem to be using it more and more. The only impact it has on me is because my first name is Jason - every time the app devs in our bullpen start talking about JSON (they pronounce it "Jay - sahn"), that little part of my brain that handles the "did I hear my name?" reflex gets activated. I think I'm slowly becoming accustomed to it and tune it out more readily, but I would be distracted constantly when the app devs first started having these conversations.

    Yeah, my brother's name is Jason. I have a similar problem.

    I ran into similar issues when working with a dev team working with that product.

    First impression was not a good one of it. We had to convert from json to xml in one spot. And for whatever reason they wanted to use the same process of converting relational data to json and then to xml (stuff coming from a website that was already working direct to the database). The kicker being that we had to take all of it and strip it back down to relational data in the end.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • SQLRNNR (3/12/2013)


    Stefan Krzywicki (3/11/2013)


    wolfkillj (3/11/2013)


    Jeff Moden (3/10/2013)


    Stefan Krzywicki (3/9/2013)


    Jeff Moden (3/8/2013)


    Matt Miller (#4) (3/8/2013)


    Jeff Moden (3/7/2013)


    Revenant (3/4/2013)


    Evil Kraig F (3/4/2013)


    Revenant (3/4/2013)


    I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.

    Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.

    It was not meant at you, Craig. I have been in that situation and I know how it feels.

    I feel the same way... I just can't understand why anyone would actually use XML. πŸ˜‰

    Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.

    Kind of like any other tool.

    I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.

    It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.

    Since you're able to directly query XML, as well, I'm not sure that's an advantage over XML. Based on what you said about JSON taking only 2/3rds the space of XML, I'll say they're headed in the right direction but it's still bloated compared to more conventional means.

    I don't really have a dog in the XML/JSON fight, and I know very little about JSON, but our app developers seem to be using it more and more. The only impact it has on me is because my first name is Jason - every time the app devs in our bullpen start talking about JSON (they pronounce it "Jay - sahn"), that little part of my brain that handles the "did I hear my name?" reflex gets activated. I think I'm slowly becoming accustomed to it and tune it out more readily, but I would be distracted constantly when the app devs first started having these conversations.

    Yeah, my brother's name is Jason. I have a similar problem.

    I ran into similar issues when working with a dev team working with that product.

    First impression was not a good one of it. We had to convert from json to xml in one spot. And for whatever reason they wanted to use the same process of converting relational data to json and then to xml (stuff coming from a website that was already working direct to the database). The kicker being that we had to take all of it and strip it back down to relational data in the end.

    There are some web tools we want to use that should turn JSON files into manager candy (Charts and graphs) quickly. For this kind of thing, it is more lightweight than database connections, is local so you don't have to worry about connectivity and is one way so I don't have to worry about re-importing it.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • Stefan Krzywicki (3/12/2013)


    SQLRNNR (3/12/2013)


    Stefan Krzywicki (3/11/2013)


    wolfkillj (3/11/2013)


    Jeff Moden (3/10/2013)


    Stefan Krzywicki (3/9/2013)


    Jeff Moden (3/8/2013)


    Matt Miller (#4) (3/8/2013)


    Jeff Moden (3/7/2013)


    Revenant (3/4/2013)


    Evil Kraig F (3/4/2013)


    Revenant (3/4/2013)


    I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.

    Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.

    It was not meant at you, Craig. I have been in that situation and I know how it feels.

    I feel the same way... I just can't understand why anyone would actually use XML. πŸ˜‰

    Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.

    Kind of like any other tool.

    I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.

    It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.

    Since you're able to directly query XML, as well, I'm not sure that's an advantage over XML. Based on what you said about JSON taking only 2/3rds the space of XML, I'll say they're headed in the right direction but it's still bloated compared to more conventional means.

    I don't really have a dog in the XML/JSON fight, and I know very little about JSON, but our app developers seem to be using it more and more. The only impact it has on me is because my first name is Jason - every time the app devs in our bullpen start talking about JSON (they pronounce it "Jay - sahn"), that little part of my brain that handles the "did I hear my name?" reflex gets activated. I think I'm slowly becoming accustomed to it and tune it out more readily, but I would be distracted constantly when the app devs first started having these conversations.

    Yeah, my brother's name is Jason. I have a similar problem.

    I ran into similar issues when working with a dev team working with that product.

    First impression was not a good one of it. We had to convert from json to xml in one spot. And for whatever reason they wanted to use the same process of converting relational data to json and then to xml (stuff coming from a website that was already working direct to the database). The kicker being that we had to take all of it and strip it back down to relational data in the end.

    There are some web tools we want to use that should turn JSON files into manager candy (Charts and graphs) quickly. For this kind of thing, it is more lightweight than database connections, is local so you don't have to worry about connectivity and is one way so I don't have to worry about re-importing it.

    It's all about the right use of the tool. In my experience it was a terrible idea. In yours, it seems to be an appropriate idea that could work.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Stefan Krzywicki (3/12/2013)


    SQLRNNR (3/12/2013)


    Stefan Krzywicki (3/11/2013)


    wolfkillj (3/11/2013)


    Jeff Moden (3/10/2013)


    Stefan Krzywicki (3/9/2013)


    Jeff Moden (3/8/2013)


    Matt Miller (#4) (3/8/2013)


    Jeff Moden (3/7/2013)


    Revenant (3/4/2013)


    Evil Kraig F (3/4/2013)


    Revenant (3/4/2013)


    I always find it frustrating when someone asks me or someone else to do things for which T-SQL was not meant, in this case parsing multilevel XML with multiple occurrences of the same tag, yet prohibits use of a tool that would make it a breeze - in this case XML LINQ via CLR Integration.

    Sorry Revenant. Don't mean to be the cause of your frustration in this case. Clean CLR isn't what scares my DBA's, it's letting my app coders loose with it.

    It was not meant at you, Craig. I have been in that situation and I know how it feels.

    I feel the same way... I just can't understand why anyone would actually use XML. πŸ˜‰

    Well I'd say XML would be like a lot of other items -it's a tool in the arsenal. Use it correctly and it can be VERY useful; use it badly or in the wrong context, and it blows up in your face.

    Kind of like any other tool.

    I strongly agree with the "right tool" sentiment. I just don't agree that XML is the right tool for the transmittal of data destined for a relational database. It seems like using a 100 ton crane to turn a monkey wrench especially when it's used to transmit otherwise flat data for a single database entity. Since I'm mostly a data troll, I've not read up on JSON but if it's a markup language that requires description tags for each row or each element, I'm not going to be very happy with that for data transmission, either.

    It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps.

    Since you're able to directly query XML, as well, I'm not sure that's an advantage over XML. Based on what you said about JSON taking only 2/3rds the space of XML, I'll say they're headed in the right direction but it's still bloated compared to more conventional means.

    I don't really have a dog in the XML/JSON fight, and I know very little about JSON, but our app developers seem to be using it more and more. The only impact it has on me is because my first name is Jason - every time the app devs in our bullpen start talking about JSON (they pronounce it "Jay - sahn"), that little part of my brain that handles the "did I hear my name?" reflex gets activated. I think I'm slowly becoming accustomed to it and tune it out more readily, but I would be distracted constantly when the app devs first started having these conversations.

    Yeah, my brother's name is Jason. I have a similar problem.

    I ran into similar issues when working with a dev team working with that product.

    First impression was not a good one of it. We had to convert from json to xml in one spot. And for whatever reason they wanted to use the same process of converting relational data to json and then to xml (stuff coming from a website that was already working direct to the database). The kicker being that we had to take all of it and strip it back down to relational data in the end.

    There are some web tools we want to use that should turn JSON files into manager candy (Charts and graphs) quickly. For this kind of thing, it is more lightweight than database connections, is local so you don't have to worry about connectivity and is one way so I don't have to worry about re-importing it.

    "It is, but the construction means that the same size of data fits in a file 2/3 the size of an XML file and it is directly queryable which makes it good for client-side apps."

    I see JSON getting traction with Web Services. Using JSON as native format for WCF new gen significantly decreases the size of exchanged data: not only that the payload is smaller, you also dispense with the bulky SOAP envelope.

    I am curious whether T-SQL will get native tools for handling JSON.

  • 'Thought I'd change my avatar to me - or something that looks a little like me. I haven't been around SSC much lately, work's been way too busy.

    But anyway, I'm now the V.P. of Boulder, Colorado's SSUG and if any of you are speakers and are willing to give a presentation for our group, just let me know. We have openings starting in May. 'Good excuse to come see Colorado if you haven't been here!

    Steve, I guess you get a pass _this time_ since you presented for us recently. Thanks again for your presentation. I think it was on SQL encryption - or injured horses - or something. πŸ˜€

    Mark

    The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking

  • mtillman-921105 (3/12/2013)


    'Thought I'd change my avatar to me - or something that looks a little like me. I haven't been around SSC much lately, work's been way too busy.

    But anyway, I'm now the V.P. of Boulder, Colorado's SSUG and if any of you are speakers and are willing to give a presentation for our group, just let me know. We have openings starting in May. 'Good excuse to come see Colorado if you haven't been here!

    Steve, I guess you get a pass _this time_ since you presented for us recently. Thanks again for your presentation. I think it was on SQL encryption - or injured horses - or something. πŸ˜€

    Mark

    I'll come back this year, just not sure when. Summer is probably better, so I'll aim for a July/Aug talk once I get my schedule squared away.

  • Thanks a lot Steve, we sure appreciate that. We'll be looking forward to it.

    Mark

    The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking

  • jcrawf02 (3/12/2013)


    I have the same understanding of the original premise of XML (simplified SGML that is supposed to promote human-readability within extensible documents), but fail to see how this extends the "semantic web" idea, which is what it was supposed to do. At least, I don't understand how stuffing *everything* into XML makes searching for anything easier.

    It doesn't, of course. Attempts to make it search easier by stuffing things into XML are usually good examples of misuse of XML, doomed to fail in their objective of facilitating search. Depending what sort of search capability is needed and the nature of the "everything" concerned the appropriate thing to stuff things into might be a logic-programming language, a constraint-programming system, a relational dbms, a network DBMS (eg IDMSX), an object base, a collection of indexed sequential files with cross-indexing, a set of old-fashioned filing cabinets with an old-fashioned card index, or some combination of the forgoing, or something else altogether (which I suppose might sometimes be an XML structure). More than 40 ago people were playing with software support for contend addressed data stores; hardware support for content addressed filestore also first popped up back in those days; generally those developments did more to facilitate search that XML is ever likely to.

    Tom

  • WayneS (3/11/2013)


    Jeff Moden (3/10/2013)


    dwain.c (3/10/2013)


    Jeff Moden (3/8/2013)


    ...Since I'm mostly a data troll...

    Does that mean you live under a bridge on Al Gore's information superhighway?

    Nah... I've gone wireless. πŸ˜›

    That ancient laptop of yours does wireless? Dang... how... modern of you

    BWAA-HAA!!! You mean how Moden of me. πŸ˜€

    --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)

  • jcrawf02 (3/12/2013)


    WayneS (3/11/2013)


    Jeff Moden (3/10/2013)


    dwain.c (3/10/2013)


    Jeff Moden (3/8/2013)


    ...Since I'm mostly a data troll...

    Does that mean you live under a bridge on Al Gore's information superhighway?

    Nah... I've gone wireless. πŸ˜›

    That ancient laptop of yours does wireless? Dang... how... modern of you

    It' a VLA (Very Large Abacus) πŸ˜›

    It's one of them thar new fangled self-standing abacuses (is that a word?).. You can see the antenna. It's in the base. The movement of the beads power it.

    --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 (3/12/2013)


    jcrawf02 (3/12/2013)


    WayneS (3/11/2013)


    Jeff Moden (3/10/2013)


    dwain.c (3/10/2013)


    Jeff Moden (3/8/2013)


    ...Since I'm mostly a data troll...

    Does that mean you live under a bridge on Al Gore's information superhighway?

    Nah... I've gone wireless. πŸ˜›

    That ancient laptop of yours does wireless? Dang... how... modern of you

    It' a VLA (Very Large Abacus) πŸ˜›

    It's one of them thar new fangled self-standing abacuses (is that a word?).. You can see the antenna. It's in the base. The movement of the beads power it.

    Is that a Tally Table?

  • Jeff Moden (3/12/2013)


    jcrawf02 (3/12/2013)


    WayneS (3/11/2013)


    Jeff Moden (3/10/2013)


    dwain.c (3/10/2013)


    Jeff Moden (3/8/2013)


    ...Since I'm mostly a data troll...

    Does that mean you live under a bridge on Al Gore's information superhighway?

    Nah... I've gone wireless. πŸ˜›

    That ancient laptop of yours does wireless? Dang... how... modern of you

    It' a VLA (Very Large Abacus) πŸ˜›

    It's one of them thar new fangled self-standing abacuses (is that a word?).. You can see the antenna. It's in the base. The movement of the beads power it.

    There's an upgrade available:

    Jason Wolfkill

  • Happy Pi day.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • SQLRNNR (3/14/2013)


    Happy Pi day.

    I'm looking forward to Pi minute in 1 hour, 17 minutes.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • Stefan Krzywicki (3/14/2013)


    SQLRNNR (3/14/2013)


    Happy Pi day.

    I'm looking forward to Pi minute in 1 hour, 17 minutes.

    Well, you will be 5 hours late then. And even if you had been using dbcc timewarp to correct for the timezone and lose 5 hours you should still have been waiting for another 3.1415927 seconds anyway, just to get the pi day, pi minute, and pi sec all at once (and that only works because datetime2 doesn't provide any more decimal places).

    Tom

Viewing 15 posts - 39,121 through 39,135 (of 66,547 total)

You must be logged in to reply to this topic. Login to reply