Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««7891011»»

"Real" copy of Codd's 12 (13) Rules for RDBMS Expand / Collapse
Author
Message
Posted Thursday, August 12, 2010 8:53 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:14 PM
Points: 37,107, Visits: 31,665
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
"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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #968249
Posted Thursday, August 12, 2010 9:03 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 9:11 AM
Points: 8,844, Visits: 9,406
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
Post #968258
Posted Thursday, August 12, 2010 9:17 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 754, Visits: 3,816
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
Post #968284
Posted Thursday, August 12, 2010 9:58 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 754, Visits: 3,816
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
Post #968348
Posted Friday, August 13, 2010 10:36 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:14 PM
Points: 37,107, Visits: 31,665
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?

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

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #969344
Posted Friday, August 13, 2010 10:38 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:14 PM
Points: 37,107, Visits: 31,665
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
"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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #969345
Posted Saturday, August 14, 2010 10:10 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 9:11 AM
Points: 8,844, Visits: 9,406
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
Post #969404
Posted Saturday, August 14, 2010 1:23 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:14 PM
Points: 37,107, Visits: 31,665
Heh... Well said, Tom. I LOVE "evil concepts" especially in T-SQL.

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

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #969426
Posted Monday, August 16, 2010 8:36 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 754, Visits: 3,816
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?

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.

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
Post #969829
Posted Monday, August 16, 2010 9:20 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 754, Visits: 3,816
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
Post #969882
« Prev Topic | Next Topic »

Add to briefcase «««7891011»»

Permissions Expand / Collapse