tags:

views:

1662

answers:

9

Hi all. Due to weird request, I can't put null in database if there is no value. I'm wondering what can i put in the store proc for nothing instead of null.

for example: insert into blah (blah1) values (null). Is there something like nothing or empty for blah1 instead using 'null'.

A: 

Conceivably you could use an empty string, but null is the only thing that's really nothing.

Why can't you use null?

Telos
+4  A: 

I would push back on this bizarre request. That's exactly what NULL is for in SQL, to denote a missing or inapplicable value in a column.

Is the requester experiencing grief over SQL logic with NULL?

edit: Okay, I've read your reply with the extra detail about this job assignment (btw, generally you should edit your original question instead of posting more information in an answer).

You'll have to declare all columns as NOT NULL and designate a special value in the domain of that column's data type to signify "no value." The appropriate value to choose might be different on a case by case basis, i.e. zero may signify nothing in a person_age column, but it might have significance in an items_in_stock column.

You should document the no-value value for each column. But I suppose they don't believe in documentation either. :-(

Bill Karwin
I agree. It's weird request. They use Access for DB so i guess that's telling you something. The guy that i'm working for told me they hate null in the db. They prefer it to be nothing but isn't nothing basically mean null?
Jack
Yes, NULL indicates the absence of a value, so that you don't have to designate one value (which you might need later) to signify 'nothing.'
Bill Karwin
They need to be more specific than they "hate null." I hate division by zero exceptions, but I don't stop using zero.
Bill Karwin
A: 

What is the table definition? What is the error message?

devio
A: 

Is null is a valid value for whatever you're storing?

  • Use a sentry value like INT32.MaxValue, empty string, or "XXXXXXXXXX" and assume it will never be a legitimate value
  • Add a bit column 'Exists' that you populate with true at the same time you insert.

Edit: But yeah, I'll agree with the other answers that trying to change the requirements might be better than trying to solve the problem.

Jimmy
+1  A: 

Depends on the data type of the column. For numbers (integers, etc) it could be zero (0) but if varchar then it can be an empty string ("").

I agree with other responses that NULL is best suited for this because it transcends all data types denoting the absence of a value. Therefore, zero and empty string might serve as a workaround/hack but they are fundamentally still actual values themselves that might have business domain meaning other than "not a value".

(If only the SQL language supported a "Not Applicable" (N/A) value type that would serve as an alternative to NULL...)

Ray Vega
Unless it is a field for which zero is a valid value. You would not want a field that stores temperature to default to zero.
TGnat
@TGnat- yes. good point. i needed to update my response to reflect the inherent weekness of that approach.
Ray Vega
(I've read that in the early days of SQL there was a proposal to have two "NULL" values -- one for absent value, and one for inapplicable.)
Bill Karwin
@Bill Karwin- yup. i recalled the same and add a link to wikipedia mentioning that. ("..."Missing but Applicable" and "Missing but Inapplicable", known as A-values and I-values,..")
Ray Vega
A: 

If you're using a varchar or equivalent field, then use the empty string.

If you're using a numeric field such as int then you'll have to force the user to enter data, else come up with a value that means NULL.

I don't envy you your situation.

Jason Lepack
A: 

There's a difference between NULLs as assigned values (e.g. inserted into a column), and NULLs as a SQL artifact (as for a field in a missing record for an OUTER JOIN. Which might be a foreign concept to these users. Lots of people use Access, or any database, just to maintain single-table lists.) I wouldn't be surprised if naive users would prefer to use an alternative for assignments; and though repugnant, it should work ok. Just let them use whatever they want.

le dorfier
A: 

Hi all. Thank for the reply. This shop that i'm currently work at use some old legacy program and code. The two programmers that i'm working with both use VB6 with MS Access as back end and the application that i'm converting to ASP.net is from VietWar era. I don't like the requirement either but was told if the value is set to null in the record. It'll break thing.

I got the feeling that this shop is very old school and i don't mean that in a good way. There is no source control, unit test...etc. and the fact of the matter is code are test on production server. That just crazy. I don't like it since i just work at a shop with modern approach to software engineering for two years using C# until the company lay us off.

Jack
Ask them what value they want to use. Their existing software is expecting something specific, so we can't really answer the question.Then yell at them and tell them to use null... this is what it's for!
Telos
Condolences. Best of luck with your next job.
Bill Karwin
Yes that is horrible situation to fall in after your previous job.
Ray Vega
@Telos, I just did. They told me '' empty string... Now that i think about it a lot of value in their MS Access are nvarchar. I actually convert the data to what they really represent.
Jack
Ok, I was wrong... we can guess what they want since that's what I guessed in my answer! ;) If you're converting the data types it's going to break their apps anyway though, might as well force null through as well.
Telos
A: 

There is some validity to the requirement to not use NULL values. NULL values can cause a lot of headache when they are in a field that will be included in a JOIN or a WHERE clause or in a field that will be aggregated.

Some SQL implementations (such as MSSQL) disallow NULLable fields to be included in indexes.

MSSQL especially behaves in unexpected ways when NULL is evaluated for equality. Does a NULL value in a PaymentDue field mean the same as zero when we search for records that are up to date? What if we have names in a table and somebody has no middle name. It is conceivable that either an empty string or a NULL could be stored, but how do we then get a comprehensive list of people that have no middle name?

In general I prefer to avoid NULL values. If you cannot represent what you want to store using either a number (including zero) or a string (including the empty string as mentioned before) then you should probably look closer into what you are trying to store. Perhaps you are trying to communicate more than one piece of data in a single field.

Chris