|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Saturday, February 13, 2010 12:45 AM
Points: 553,
Visits: 18
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, March 14, 2013 9:46 AM
Points: 142,
Visits: 285
|
|
| I've never used this xml procedure before so it would really be nice if the author had used a decent coding style to make it easier to read. This is especially true when it comes to dynamic SQL. So, I'll just pack it off to my sandbox and figure it out there.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, May 08, 2007 5:25 AM
Points: 1,
Visits: 1
|
|
| we're not all mathematical genius you know
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Monday, February 09, 2009 7:44 PM
Points: 282,
Visits: 37
|
|
| Found the proc and concept interesting, but had a few issues. The syntax of the proc statement wasn't explained at all, and it would have taken five seconds to explain some of the newer functionality. The point of the exercise wasn't fully explained, and the values in the end product were nebulous. Obviously the author knows more than I do, but the point of the exercise was to learn not to show off.
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Tuesday, September 04, 2012 2:04 AM
Points: 263,
Visits: 324
|
|
I would not have minded a bit more explaination on the syntax, but that I work around. I would have liked some idea/example of how this is used though. Seems like an academic excercise?
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Monday, February 14, 2011 8:11 AM
Points: 5,
Visits: 16
|
|
I didn't get the impression that the author was trying to show off, and most of the comments are well founded, but I especially agree with the "answers were nebulous" comment. I can go look up syntax and new functions but it would be nice if the author would provide a follow-up with a few examples where this finely-tuned result set would save us time elsewhere.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Thursday, May 20, 2010 10:04 AM
Points: 54,
Visits: 38
|
|
This article does not mention an important thing, namely that SQL (at least MS SQL) has no just 2 truth values but 3: true, false, and unknown(*). 'unknown' may stem from comparing NULL values (**), among other things. Boolean operators work as you'd expect if you interpret "unknown" as "don't know whether true or false" or "maybe true maybe false": true AND unknown = unkown (since the value of 'true AND x' depends on whether x is true or false); true OR unknown = true (the value of 'true OR x' is 'true' regardless of x); etc.
(*) not sure what's the official name for that 3rd value.
(**) e.g.
select 'error' where 0 = NULL
returns nothing, not because 0 = NULL evaluates to "false", but because 0 = NULL evaluates to "unknown". Indeed, the "opposite" condition also returns nothing:
select 'error' where not (0 = NULL)
because '0 = null' evaluates to 'unknown', then 'not (0 = null)' evaluates to the logical negation of 'unknown' which is again 'unknown'.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, August 10, 2007 3:09 PM
Points: 2,
Visits: 1
|
|
A few years ago, I was trying to figure out how 9 combinations of activities, 9 "if this, then that" trials and all their combinations, caused certain events to happen in a help desk developed by a major company. Their engineers couldn't answer my questions as to why I was getting an odd result when certain actions were combined. I decided to hand-build a truth table to show each possible case (in between my regular job duties) and after a month was able to show that a certain sequence of events gave a "predictable" but undesirable result that no one had anticipated. I sent the tables to the engineers and they fixed the "bug" Since the possible results of a set of actions grow exponentially, if I had had this procedure I would have saved myself hours (days) of work! Thank you for the procedure - it's a great help so, absolutely, keep showing off!!! 
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Tuesday, January 17, 2012 10:37 PM
Points: 14,
Visits: 42
|
|
I also declare myself ignorant, and read the article looking for a practical everyday application. Not that the article wasn't interesting and valid, it's just that you normally expect a general and pragmatic application for most articles you see on this site... That being said, I'm sure that anybody in this specific field would appreciate the article, and being able to use SQL to tackle this problem. Probably the first thing to do is to learn more about what a Truth Table is: http://en.wikipedia.org/wiki/Truth_table The Wikipedia mentions that it is used in digital/electronic design as an alternative to logic gates or code, including the design of a bit adder. I remember building a 4 bit adder (or was it 2 bit?) in college using logic gates, and I can see how having a truth table could have been useful in debugging it (maybe having expresions for intermediate outputs). The Wikipedia article has links to a couple online truth table generators, in case you require generating such a table, and don't have a SQL server handy to run the code in the article...
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Wednesday, May 01, 2013 7:27 AM
Points: 905,
Visits: 8,640
|
|
I found the article generally interesting. As a tester, I often need to build truth tables and this tool could come in handy.
However, I've never come across the "IMPLIES" operator before. The article gives:
Implies P IMP Q ~P | Q
What exactly does this mean? From the meaning of implies, I would expect it to mean: 1. If P is true then Q must be true. 2. If P is false, then Q may be true. But, given the logic, I have no idea where he's trying to go.
Steve Eckhart
|
|
|
|