NULL Equals NULL?
-
What Mike C can't make in reasonning he tries to establish by pointing out simple copy and paste errors...He does as if he does not understand what is my intent but infact he does...just to be able to nail me...LOL!!
create table active_personnel(
employee_id int not null identity primary key,
employee_code varchar(10) not null,
employee_name varchar(50) not null,
hire_date datetime not null
)
create table terminated_personnel(
employee_id not null , --> references active_personnel --> foreign key of active_personnel
terminated_date datetime not null
)
[Snipped]
-
//You are quite a piece of work, and I think I'm pretty much through debating anything more with you, as you're completely illogical in your arguments, your code is horrible and bug-infested, you're very offensive to the senses, and you haven't produced anything of value yet. Best of luck and I look forward to seeing you contribute something of value.//
Let people judge for themselves...
Mike C,
You are a self aggrandizing ignorant who have produced nothing but gibberish since the beginning of the thread...You lack intellectual honnesty at all level for the purpose of self promotion and spread so much nonsense I can not count...You deserve simply to be ignored.
-
A new BS...I dare Mike C to produce books...papers...
Codd never made any work focused on NULL. And if he did talk about NULLS it was ONLY to warn against their use...As he did against dupplicated records...
Dr. Codd's Rule #3, from his "12 Rules", first published in the article "Is Your Database Really Relational? (Parts 1 and 2)", ComputerWorld, October 14, 1985 and October 21, 1985:
Rule 3: Systematic Treatment of Null Values
A field should be allowed to remain empty. This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a non-null field constraint that prevents null values in a specific table column.
And C.J. Date quoted Codd in his book AN INTRODUCTION TO DATABASE SYSTEMS (5th Edition), pages 389 - 393:
3. Systematic treatment of null values
The DBMS is required to support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number," in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.
-
//If you look past the insults back and forth, this could have been a really good discussion. I thank Cimode for offering his ideas but wish it could have been done a bit more tactful as to not turn off readers but rather to educate us. I consider myself a lifetime student so I really enjoy reading ideas/theories when there are different points-of-view. I think we should all try to keep an open mind to ideas and learning new/alternate ways at doing something.//
There are no ten ways to expose fallacies... Sometimeyou have to call a spade a spade....When something is wrong, somebody has to stand and say it...Openmindness should not be an excuse for ignoring that some smart people already identified the issues such as NULL and brought answers to them...
Ignoring the history of database management only leads to repeat over and over the same mistakes and reinventing square wheels...
If people were sufficiently educated at the first place in database formal theory, they would probably realize for themselves what I am trying to expose...
-
//Rule 3: Systematic Treatment of Null Values
A field should be allowed to remain empty. This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a non-null field constraint that prevents null values in a specific table column.
And here it is from C.J. Date's book AN INTRODUCTION TO DATABASE SYSTEMS (5th Edition), pages 389 - 393://
Is that a woork focused on NULLS
Was expecting that. Codd was pressured to write such BS..by his editor...It's a known story
//
3. Systematic treatment of null values
The DBMS is required to support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number," in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.//
Your lack of intellectual honnesty has striken once again..
A systematic treatment of missing data does not mean using NULLS...Quite the opposite
You have no clue of what DATE is writing which reveals your profound ignorance. He and DARWEN wrote next an article to clarify his position called
*How to handle missing data without using NULLS*..;the DBMS should handle the treatment...If not convinced
Check out
thethirdmanifesto.com
How to handle
Missing data
-
Gosh only an ignorant could mistake a Systematic Treatment of Missing Data for using NULLS in the firs place...NULLS are the WORST possible way to handle missing data and it is certainy not automatic...
-
Link onto DATE and DARWEN's work on systematic ways for the treatment of missing data...What Mike C mistakes for using NULLS
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf
-
I'll leave this thread with this: Cimode, if you had come to the discussion and simply said "I disagree with X, Y, and Z that you wrote; and this is why I disagree with you...", I would have been the first one to sit down and listen to you wholeheartedly. Instead, Cimode, you attacked in your first post, calling me names, saying things about my level of knowledge, etc., and then attacking anyone who mentioned that you needed to calm down, or you needed to fix your code "proofs". Unfortunately you don't know me from Adam, and have very little to say about what I may or may not know on any level.
I may even agree with a lot that you have to say, even though you are arguing Relational Model theory, and I am very plainly discussing ANSI SQL and T-SQL reality in my articles. By your own admission, SQL has not been based on RM in over a decade; so your entire argument seems more than a little superfluous, and all of your aggression appears to be 100% misplaced.
The reality is that most of us don't always get to decide how our databases are designed. The reality is that it may already be designed a certain way and we just inherited it. The reality is that we may need to use outer joins to retrieve data. The reality is that we may have to deal with NULLs at some point; and in fact, the real reality is that most of us have to deal with them all the time. And for everyone in the world (other than you) who has to deal with NULLs in one form or another, we need to know how they behave, why they behave that way, and how to properly handle them in the real world in order to minimize issues with them.
You have a nice night, and I certainly hope you feel better in the morning.
-
//I'll leave this thread with this: Cimode, if you had come to the discussion and simply said "I disagree with X, Y, and Z that you wrote; and this is why I disagree with you...", I would have been the first one to sit down and listen to you wholeheartedly. Instead, Cimode, you attacked in your first post, calling me names, saying things about my level of knowledge, etc., and then attacking anyone who mentioned that you needed to calm down, or you needed to fix your code "proofs". Unfortunately you don't know me from Adam, and have very little to say about what I may or may not know on any level.//
I really have NO personal grudge against you (I am sure you are a nice person) but against the fallacies you are vehiculating without probably not even being aware of it...You are hurting the community by spreading such nonsense. Your best course of action is to educate yourself in Database Management then you will realize what I am refering to...
One day, maybe, you may even realize I was trying to help you but I doubt this day will happen if you let arrogance drive you instead of quest for truth...
//
I may even agree with a lot that you have to say, even though you are arguing Relational Model theory, and I am very plainly discussing ANSI SQL and T-SQL reality in my articles. By your own admission, SQL has not been based on RM in over a decade; so your entire argument seems more than a little superfluous, and all of your aggression appears to be 100% misplaced.
//
Discussing SQL does not mean just identify its limitations but to understand their nature and cause...SQL is just an implementation among others...And only a through knowledge of RM may allow you to do so...
//
The reality is that most of us don't always get to decide how our databases are designed. The reality is that it may already be designed a certain way and we just inherited it. The reality is that we may need to use outer joins to retrieve data. The reality is that we may have to deal with NULLs at some point; and in fact, the real reality is that most of us have to deal with them all the time. And for everyone in the world (other than you) who has to deal with NULLs in one form or another, we need to know how they behave, why they behave that way, and how to properly handle them in the real world in order to minimize issues with them.
//
The reality is what we choose it to become...Not designing database with NULLS is the only way to guarantee not to fall into the mess of NULLS and spend more time finding hacks than solving business problems...THere are no fatalities...
//You have a nice night, and I certainly hope you feel better in the morning.//
I feel perfect but thanks for asking...
-
Check out DATE's principle of incoherence...
*It is difficult to treat in a coherent manner what is inherently incoherent*
-
Good night all from tomorrow on I will prbably banned from this NG...But that's not important...
And READ READ READ ....and do not fall in fallacies!!!
Regards all,
Cimode
-
Well, that was certainly an interesting read. Who needs Coronation Street!
So, what have I learnt today?
1. If I have a database that allows NULL values in some fields, I am now better equipped to deal with them. Thanks Mike C.
2. If I design any more databases, I should brush up on my RM theory and design missing data away from possible NULL values, thereby creating a highly normalised database. I'll be interested to see how practical that is for my business requirements as I've not tried it before. Thanks Cimode.
3. Always be polite when posting to this forum and not call people ignorant because I happen to disagree with their article.
4. Always run my code in QA and ensure I copy the whole block into the post so I don't make an error that can lead to me being misunderstood.
5. Try to manage my snippets a little better so that others can easily decipher what is my text and what is text I have copied.
6. That before I even put my two cents worth in, it is going to cost my company a few dollars any time I read 8 pages of posts in work hours.
Ummm, that's about it. Wow, what an entertaining and informing morning. I need a beer!
-
Now here's some data for your correct schema. Show us how to retrieve a list of all personnel, with their respecitve hire_date and terminated_date using your schema and SQL. No outer joins, no NULLs, and no NULL-handling allowed:
create table active_personnel(
employee_id int not null identity primary key,
employee_code varchar(10) not null,
employee_name varchar(50) not null,
hire_date datetime not null
)
create table terminated_personnel(
employee_id int not null , --> references active_personnel --> foreign key of active_personnel
terminated_date datetime not null
)
SET IDENTITY_INSERT active_personnel ON
INSERT INTO active_personnel (employee_id, employee_code, employee_name, hire_date)
VALUES (1, 'ZZZZ', 'Cimode', '2007-02-01')
INSERT INTO active_personnel (employee_id, employee_code, employee_name, hire_date)
VALUES (2, 'YYYY', 'Son of Cimode', '2007-02-01')
INSERT INTO terminated_personnel (employee_id, terminated_date)
VALUES (1, '2007-02-12')
-
Wow. Serves me right for sleeping at night.
Mike, it can be done. Not pretty, but possible:
select t.employee_ID, employee_name, hire_date, convert(varchar(20),terminated_Date)
from
(
select employee_ID, count(*) as timesAppears
from
(select Employee_ID from active_personnel
UNION ALL
select employee_ID from terminated_personnel) as d1
group by employee_ID
) as d2
inner join terminated_personnel t
on d2.employee_id = t.employee_ID
and d2.timesappears = 2
inner join active_personnel a
on a.employee_id = d2.employee_id
UNION
select a.employee_ID, employee_name, hire_date, 'Still Active'
from
(
select employee_ID, count(*) as timesAppears
from
(select Employee_ID from active_personnel
UNION ALL
select employee_ID from terminated_personnel) as d1
group by employee_ID
) as d2
inner join active_personnel a
on a.employee_id = d2.employee_id
and d2.timesAppears = 1
Oh, and BTW, you had a couple of minor typos in your script (missing a SET IDENTITY_INSERT ON and a data type declaration for employee_id in the second table, but no sweat - it's been a long thread
) -
Oh, and forgot to mention.... I found both your articles clear and on-point. I dislike NULLs for the grief they cause, but they turn up even in the best neighbourhoods, and it's better all round if we can educate people to be aware of and to deal with them.
More extremist fear-and-loathing is NOT what this world need right now, IMNSHO.
Viewing 15 posts - 61 through 75 (of 117 total)
You must be logged in to reply to this topic. Login to reply