August 12, 2010 at 8:53 am
mtillman-921105 (8/10/2010)
Jeff Moden (8/9/2010)
mtillman-921105 (8/9/2010)
Actually, this breaks a cardinal rule in database design - we are using one column for more than one kind of data. It answers two questions: Was there a test taken? and What were the results of the test? Ideally, there should be one column signifying if the blood pressure was taken and another for the results.So... let me ask the question... have you actually implemented two columns like that and for the reason you gave when only one is needed? Be honest now...
Yes, I have, usually you can do more with it than add a bit column. Maybe a date for when the BP was measured for example (and no date = no test, still no need for a NULL there). Most often, this step isn't that important. Or, I will use a special code in the column such as "-1" to designate odd results. But if the data is as sensitive as PaulB claims, I still think the best solution is a child table - in which case the NULLS in that column become superfluous anyway.
But let me ask a quesion to you Jeff, that I beleive that David Portas brought up, why are there no NULLs in the business world if they're so important? Have you ever seen a spreadsheet with them showing from a non-programmer? (Of course a file originally from a progammer doesn't count - sometimes we leave them in there. I usually try to hide them.)
Now I may be wrong about all this - I am a self-taught programmer, so it is possible that most people don't have the issues I do with NULLs.
Whether or not there are NULLs in a particular area of thought such as "business" has absolutely no bearing on either the definition or utility of NULLs anymore than "business" had anything to do with the definition and utility of zero.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 12, 2010 at 9:03 am
David Portas (8/12/2010)
I think you are confusing two very different things: the NULL marker needed to indicate an absent datum and the extra truth value needed for 3VL. It's probably because you thought I was conflating those two things - I didn't intend any such conflation
Then I don't know what your example has to do with MVL in the Codd-style system. It seems like two Not Proven verdicts are just as equal to each other as two Guilty verdicts and could therefore be handled perfectly well by a 2VL system in the database. I don't have any problem with MVL data types of that kind in my 2VL database. What I have a problem with is MVL used as the basis for data models and query languages.
If you look at a 3VL as used for verdicts in Scotland you will find that there are 3 truth values. What is your objection to using such a system as the propositional logic component of the predicate calculus component of relational algebra? This would be the strongest logic (ie closest to the top of the supra-inituistionistic logic lattice) that it is sensible to use if you believe that you can have missing data.
Since a large number of the best mathematicians in the world have devoted lots of effort during the last 100 years to reformulating mathematics in constructive logic instead of in classical logic you can be certain that relational algebra has been tackled as part of the constructivist movement in mathematics and perhaps you should consider it appropriate to follow the Brouwer line to avoid falling into any of the nasty paradoxes that can show up when a naive 2VL is used carelessly. Of course if you want to use constructive relational algebra you can't use a naive 3VL, you have to use constructive logic as the propositional logic base, ie you would have to go right to the bottom of the lattice of intermediate logics, you couldn't get away with using anything further up the lattice like a Gödel n-valued logic or a logic of bounded depth or a logic of bounded cardinality or a Gödel–Dummett logic let alone classical 2VL (which is the only co-atom in that lattice, the only thing above it is the contradictory logic obtained by adding the proposition FALSE to the axiom list). And then you have to use a Heyting Algebra to define the semantics of the logic rather than listing truth values (the smallest Heyting Algebra adequate for the task has C base elements where C is the cardinality of the continuum, so presumably you would need C truth values to express it in truth value terms; whether this cardinality is that of a constructive continuum, or that of the classical continuum is a fun question). Alternatively you could use a Kripke semantics (I've heard of those but don't know anything about them). Or maybe a
Hardware people are quite happy with multi-valued logics, the two most commonly used in hardware design are 4-valued and 9-valued; but they use two valued logic to reason about scircuits that use 4-valued or 9-valued log, so they aren't using the MVL as their reasoning mechanism and so they are not an example of using MVL as a logic as opposed to as a model of something else (that's the way you interpreted my point that using 3VL and having NULLs are not the same thing, and I really don't unerstand why).
Mathematicians on the other hand are happy with multi-valued logics as a reasoning mechanism, and indeed a very large number of mathematicians don't accept the validity of classical 2VL as something that can safely be used for reasoning about mathematics (and the ones who are happy to use 2VL for reasoning about mathematics have often spent time working with MVLs, including some very famous people: Gödel, Scott, Tarski, Post, Cohen, Kolmogorov and more).
Why do some database people believe that multi-valued logics are not acceptable? Why do they believe that it never happens that we can't deliver a value from the database because we don't know what it should be? Why don't they want a plain and simple means of dealing with that fairly common situation? Why do they pretend that using a non-classical logic is going to deliver any wrong results that wouldn't be delivered by a 2-valued logic? Why do they assume that using a multi-valued logic entails accepting NULL in some form (it doesn't) just because the converse is true? It's all beyond me.
Tom
August 12, 2010 at 9:17 am
Jeff Moden (8/12/2010)
mtillman-921105 (8/10/2010)
Jeff Moden (8/9/2010)
mtillman-921105 (8/9/2010)
Actually, this breaks a cardinal rule in database design - we are using one column for more than one kind of data. It answers two questions: Was there a test taken? and What were the results of the test? Ideally, there should be one column signifying if the blood pressure was taken and another for the results.So... let me ask the question... have you actually implemented two columns like that and for the reason you gave when only one is needed? Be honest now...
Yes, I have, usually you can do more with it than add a bit column. Maybe a date for when the BP was measured for example (and no date = no test, still no need for a NULL there). Most often, this step isn't that important. Or, I will use a special code in the column such as "-1" to designate odd results. But if the data is as sensitive as PaulB claims, I still think the best solution is a child table - in which case the NULLS in that column become superfluous anyway.
But let me ask a quesion to you Jeff, that I beleive that David Portas brought up, why are there no NULLs in the business world if they're so important? Have you ever seen a spreadsheet with them showing from a non-programmer? (Of course a file originally from a progammer doesn't count - sometimes we leave them in there. I usually try to hide them.)
Now I may be wrong about all this - I am a self-taught programmer, so it is possible that most people don't have the issues I do with NULLs.
Whether or not there are NULLs in a particular area of thought such as "business" has absolutely no bearing on either the definition or utility of NULLs anymore than "business" had anything to do with the definition and utility of zero.
I have to disagree with you there Jeff. The utility of SQL Server, and all RDBMS in general, is for business. Why remove it from its context? Business is its reason for being. This reminds me of Wittgenstein getting frustrated with philosophers and exclaiming, "Don't think! Look!" This is an interesting discussion, but I'm going to keep trying to pull it back down to Earth as I think Wittgenstein would. NULLs are here for our use rather than vice-versa. NULLs are only what we define them to be; nothing more and nothing less.
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
August 12, 2010 at 9:58 am
Not that I'm trying to put an end to this logic discussion, I'm not: but look. Can't we accept that in certain cases NULLs are useful and in others, they're not?
The truth of a statement requires it to be both valid and sound. But since mathematics and logic are abstracted beyond individual cases, they can not be said to be sound at all (there is a NULL for their soundness).
In which case, Mathematics and logic can be said to be neither true nor false, only valid or invalid.
I bring this up since I believe that we're trying to paint with too broad of strokes (yes, i.e., it depends) and if we're looking for The Truth of NULLs in logic, we're attempting the impossible. Conversly, I'm not saying that it is not worthy of consideration - of course it is.
Before, a good example of blood pressure was used as an example where the unknown was needed. That's all well and good. On the other hand, look: think of a GL table - there is no need to go adding NULLs everywhere when we add a new GL number - empty means there are no charges to that account yet. It isn't complicated - we decide that those are the rules we're following for this table and it's that simple. If someone fails to enter charges to the account - it is still going to show zero. But how is our DBMS to know when someone is failing to enter the charges anyway? Most of the time in this scenario, we're fine with assuming that if no records show charges with account X, then there are no charges (credits or debits) associated with it. It works - we're forced to be pragmatic since we're not omniscient.
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
August 13, 2010 at 10:36 pm
mtillman-921105 (8/12/2010)
I have to disagree with you there Jeff. The utility of SQL Server, and all RDBMS in general, is for business. Why remove it from its context? Business is its reason for being. This reminds me of Wittgenstein getting frustrated with philosophers and exclaiming, "Don't think! Look!" This is an interesting discussion, but I'm going to keep trying to pull it back down to Earth as I think Wittgenstein would. NULLs are here for our use rather than vice-versa. NULLs are only what we define them to be; nothing more and nothing less.
Heh... you just can't help knocking rings, can you? :hehe:
I didn't say that SQL Server wasn't used for business nor did I try to remove it from that context. I said business has nothing to do with the definition of NULL. You're also very incorrect if you think SQL Server is used only for business as you know it.
Also, you haven't been listening. I support and embrace the use of NULLs. I don't need a lecture on NULLs being "here for our use rather than vice-versa". If you believe in that, then we're probably on the same side on that issue.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 13, 2010 at 10:38 pm
mtillman-921105 (8/12/2010)
Not that I'm trying to put an end to this logic discussion, I'm not: but look. Can't we accept that in certain cases NULLs are useful and in others, they're not?
You should have stopped there. That's all I've been trying to say during this whole thing. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 14, 2010 at 10:10 am
Jeff Moden (8/13/2010)
mtillman-921105 (8/12/2010)
Not that I'm trying to put an end to this logic discussion, I'm not: but look. Can't we accept that in certain cases NULLs are useful and in others, they're not?You should have stopped there. That's all I've been trying to say during this whole thing. 😉
The real problem of course is that although most of us (I was tempted to say all those of us who are rational, but I didn't want to give offence so I refrained) hold that opinion, there are some people who regard NULLs as an device of the devil and will not accept that any useful language (or algebra or calculus) of relations could possibly include such an evil concept (or even worse, use a logic which is not good old classical 2-valued logic - no shades of grey in the semantics of their truth values).
Tom
August 14, 2010 at 1:23 pm
Heh... Well said, Tom. I LOVE "evil concepts" especially in T-SQL. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
August 16, 2010 at 8:36 am
Jeff Moden (8/13/2010)
mtillman-921105 (8/12/2010)
I have to disagree with you there Jeff. The utility of SQL Server, and all RDBMS in general, is for business. Why remove it from its context? Business is its reason for being. This reminds me of Wittgenstein getting frustrated with philosophers and exclaiming, "Don't think! Look!" This is an interesting discussion, but I'm going to keep trying to pull it back down to Earth as I think Wittgenstein would. NULLs are here for our use rather than vice-versa. NULLs are only what we define them to be; nothing more and nothing less.Heh... you just can't help knocking rings, can you? :hehe:
I didn't say that SQL Server wasn't used for business nor did I try to remove it from that context. I said business has nothing to do with the definition of NULL. You're also very incorrect if you think SQL Server is used only for business as you know it.
Also, you haven't been listening. I support and embrace the use of NULLs. I don't need a lecture on NULLs being "here for our use rather than vice-versa". If you believe in that, then we're probably on the same side on that issue.
Actually, what I should have have said was that most of us would not even care about NULLs if it weren't for SQL Server or other DBMS (especially those of us on this website). In that sense, it is their reason for being.
I was a philosophy major (and a psychology major by the way), so I started reading my book on elemetary logic about empty sets over the weekend. Now here is the clencher - it said that an empty set was represented by a zero. :w00t:
I plan to look deeper into this - I wonder what Frege would say about this for example...
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
August 16, 2010 at 9:20 am
Jeff Moden (8/13/2010)
mtillman-921105 (8/12/2010)
Not that I'm trying to put an end to this logic discussion, I'm not: but look. Can't we accept that in certain cases NULLs are useful and in others, they're not?You should have stopped there. That's all I've been trying to say during this whole thing. 😉
Jeff, that comment wasn't directed toward you specifically. My apologies if I have somehow offended you. Often when I attack an idea, I don't hold back. But I'm not trying to offend people (no "to the man" arguments here). (I blame my training in philosophy for this trait.)
I may have sounded as though I detested NULLs at first, but it is more the way SQL Server seems to force them upon us rather than give us the option that I find objectionable (although I know that there are ways around using NULLs in a lot of situations).
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
August 16, 2010 at 7:46 pm
mtillman-921105 (8/16/2010)
I was a philosophy major (and a psychology major by the way), so I started reading my book on elemetary logic about empty sets over the weekend. Now here is the clencher - it said that an empty set was represented by a zero.
I won't argue that an "empty set" is represented by a zero but that has nothing to do with NULL's in a database.
Again, you should have just stopped where you were because that's all that matters about NULL's in a DB.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 17, 2010 at 2:16 am
Hi Jeff,
Here you'll find 3 papers from E.F.Codd ,
A Relational Model of Data for Large Shared Data Banks
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.5286&rep=rep1&type=pdf
Extending the Database Relational Model to Capture More Meaning
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.9469&rep=rep1&type=pdf
RELATIONAL COMPLETENESS OF DATA BASE SUBLANGUAGES
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9277&rep=rep1&type=pdf
HTH
Alain
August 17, 2010 at 5:32 am
mtillman-921105 (8/16/2010)
I was a philosophy major (and a psychology major by the way), so I started reading my book on elemetary logic about empty sets over the weekend. Now here is the clencher - it said that an empty set was represented by a zero.
Did the book really say "a zero", or did you mistake the Greek letter phi (f or F) - which is the usual symbol used to denote the empty set - for a 0? Or do you have it upside down, did it actually say "in standard set theory the empty set is used to denote the (ordinal) number zero"? It's quite possible that you are quoting correctly and your elementary logic did say something quite bizarre, but in my experience the most common reason for someone to claim that the empty set is represented by 0 is one of those two misunderstandings. Mistaking F for 0 is particularly common amongst those who grew up with batch computoing, since there was a fairly common convention that on coding sheets phi should be used for zero and theta for letter "O" in order to disambiguate them for the girls who typed from the coding sheets, whether to produce punched cards, or paper tape, or for direct data entry to the computer; perhaps your book was written - or proof-edited - by someone from that generation.
Tom
August 17, 2010 at 6:22 am
Tom.Thomson (8/17/2010)
mtillman-921105 (8/16/2010)
I was a philosophy major (and a psychology major by the way), so I started reading my book on elemetary logic about empty sets over the weekend. Now here is the clencher - it said that an empty set was represented by a zero.Did the book really say "a zero", or did you mistake the Greek letter phi (f or F) - which is the usual symbol used to denote the empty set - for a 0? Or do you have it upside down, did it actually say "in standard set theory the empty set is used to denote the (ordinal) number zero"? It's quite possible that you are quoting correctly and your elementary logic did say something quite bizarre, but in my experience the most common reason for someone to claim that the empty set is represented by 0 is one of those two misunderstandings. Mistaking F for 0 is particularly common amongst those who grew up with batch computoing, since there was a fairly common convention that on coding sheets phi should be used for zero and theta for letter "O" in order to disambiguate them for the girls who typed from the coding sheets, whether to produce punched cards, or paper tape, or for direct data entry to the computer; perhaps your book was written - or proof-edited - by someone from that generation.
I never made that connection, that's why people slash their zeroes....huh, learn something new every day...
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
August 17, 2010 at 8:13 am
Alain Rastoul (8/17/2010)
Hi Jeff,Here you'll find 3 papers from E.F.Codd ,
A Relational Model of Data for Large Shared Data Banks
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.5286&rep=rep1&type=pdf
Extending the Database Relational Model to Capture More Meaning
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.9469&rep=rep1&type=pdf
RELATIONAL COMPLETENESS OF DATA BASE SUBLANGUAGES
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9277&rep=rep1&type=pdf
HTH
Alain
Finally! Someone get's back to the original subject of my poor ol' hijacked thread! Thanks, Alain. I'll take a look.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 91 through 105 (of 106 total)
You must be logged in to reply to this topic. Login to reply