2 questions... first x > '' vs x <> ''

Question

2 questions... first x > '' vs x <> ''

Viewing 9 posts - 16 through 23 (of 23 total)

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

David.Poole SSC Guru Points: 75900 More actions · Answer 1

I've been trying to get people out of the habit of using != but they're just not buying my "<> is more readable". Do you have another reason to avoid it?

I started off as a VB programmer so <> seems more natural however C, C#, Java, Javascript, PHP etc all use !=

I'm more worried about people using Decimal(18,2) for MonthlyFee, NVARCHAR for standard English, Is_Female flags, two separate join strategies between two tables depending on the use case and nullable fields to get around the difference!

LinkedIn Profile

Paul White SSC Guru Points: 150467 More actions · Answer 2

David.Poole (11/11/2010)
On big systems you want your tables as efficient as possible and NULL values require a setting in the 192 byte record header.

What are you referring to here, David?

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Paul White SSC Guru Points: 150467 More actions · Answer 3

GSquared (11/11/2010)
And that's why there need to be two different versions of null. One for "we don't know" and another for "we don't care". (Okay, really for "don't know" vs "known no value", but the other is easier to remember.) Till then, null = "unknown value or no value".

NULL creates quite enough confusion and buggy code as it is. The thought of introducing 4-state logic is just scary.

My own personal view is to avoid NULLs wherever possible, but not to the point of absurdity.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Jeff Moden SSC Guru Points: 1003870 More actions · Answer 4

As a side bar, I already have 4 state logic... on, off, don't know, and don't care. That 4th state is data that I leave out of the database altogether. 😛

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

GSquared SSC Guru Points: 260824 More actions · Answer 5

Paul White NZ (11/14/2010)
GSquared (11/11/2010)
And that's why there need to be two different versions of null. One for "we don't know" and another for "we don't care". (Okay, really for "don't know" vs "known no value", but the other is easier to remember.) Till then, null = "unknown value or no value".
NULL creates quite enough confusion and buggy code as it is. The thought of introducing 4-state logic is just scary.
My own personal view is to avoid NULLs wherever possible, but not to the point of absurdity.

Jeff Moden (11/14/2010)
As a side bar, I already have 4 state logic... on, off, don't know, and don't care. That 4th state is data that I leave out of the database altogether. 😛

Paul: I'm not sure that a new value other than null, for "no value", would be more confusing to people than the current "null" issues.

Jeff: Your 4th data state is one of the common issues I see in poorly designed databases. "Why is that field in there?" "Well, we're not sure." Definitely agree with you on that one.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Paul White SSC Guru Points: 150467 More actions · Answer 6

GSquared (11/15/2010)
Paul: I'm not sure that a new value other than null, for "no value", would be more confusing to people than the current "null" issues.

Well I suppose there are three possible outcomes: more/same/less confusion. Assuming 4-state logic, I am leaning toward 'same/less' being unlikely.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

grahamc SSCertifiable Points: 6762 More actions · Answer 7

Well one argument (not seen in this thread yet) for the case of using NULL values is the introduction of SPARSE columns. This link discusses the space savings based on field type:

http://msdn.microsoft.com/en-us/library/cc280604.aspx

mudbuddy11 SSC Veteran Points: 276 More actions · Answer 8

All of you have been very helpful. I want to thank you all. Paul, Steve, David, and anyone else I forgot... Thank You.

I WILL NOT be using any kind of 4 state logic. That would drive my old oracle developer CRAZY(and maybe me too).

I will definetely check for isnull when passing a value through .net... and we do use stored procs(often but not exclusively) for the DAL.

we dont use sparse columns yet, but if we do... I have an argument for nulls.

I'm honestly amazed at the fear nulls create. It is confusing, but I thought there was more of a consensus... at least between professionals.

thanks again guys(and potential gals)

I appreciate all of your comments.

David.Poole SSC Guru Points: 75900 More actions · Answer 9

grahamc (11/15/2010)
Well one argument (not seen in this thread yet) for the case of using NULL values is the introduction of SPARSE columns. This link discusses the space savings based on field type:
http://msdn.microsoft.com/en-us/library/cc280604.aspx

My first reaction to sparse columns was wow. My 2nd reaction was "Microsoft makes bad practise pain free"! It's a bit like surrounding objects with square brackets. It lets developers use reserved words and bad naming conventions.

LinkedIn Profile