I have database in which data is imported from the other table. if data is empty there. so while importing to here it became null. When i query the columns like, name doesnot starts with 'a', it should return all records whose name doesn't start with 'a'. including NULL/empty column. its returning epty records but not null. But i need null feilds also. I useing hibernate and sqlserver 2005. how to achieve this.?please help.
Thanks
Null and Empty are different things.
When you say "Retrieve all the entries that do not start with a" it means that it will retrieve all the entries with something that is not a. Null is not something. Null is nothing. Empty is something.
You should modify your query to add OR IS NULL, to retrieve also the null fields.
From Wiki:
Null is a special marker used in Structured Query Language (SQL) to indicate that a data value does not exist in the database. Introduced by the creator of the relational database model...
...Since Null is not a member of any data domain, it is not considered a "value", but rather a marker (or placeholder) indicating the absence of value. Because of this, comparisons with Null can never result in either True or False, but always in a third logical result, Unknown.
Checkout this discussion.
Related
I have a RDBMS table in DB2 where a column is defined as "ARMTST" VARCHAR(10) NOT NULL DEFAULT
I was checking data on table and see rows with no value in this column ( Via Toad Viewer) but when I run this query , SELECT COUNT ( * ) FROM ACTIVITY WHERE ARMTST IS NULL; I get result as zero rows.
Attached is screen shot for SELECT ARMTST FROM ACTIVITY ; which shows empty column values for certain rows.
Are these columns not empty even though shown so in UI? Default value is not specified in CREATE TABLE script.
I don't think that code will be able to insert empty values.
An empty string is not null (well, except for on Oracle, but people hate them for that). Often in databases, null is used to represent "we don't know (yet)", while empty is "not present".
Consider middle names. Many people in America (and other countries) have middle names (not your given name, not your family name).
If you (casually) ask me for my name and I respond with only a first and last name (likely, in my case, or you might only get my first name!), what do you know about my middle name? Nothing. You don't know if I have one. This is null - you don't know if I have one, and if so, what it is.
But if you ask me "officially" (like for legal reasons), I'm obligated to use my full name - if I have one (or more), I have to include my middle name. So there's two outcomes here:
I have no middle name. That result is blank - we know the answer, and it was nothing.
I have a middle name. The result is whatever my name is.
Or consider signing up for a website. Before signing up, you are not in their system. Your entire record is null - it doesn't exist. After signing up, though, you get a 0 post count.
So now you should have enough information for your question.
Obviously, because the column was defined as NOT NULL, you can't put a null there. So the system has to default to something else. Since including any data (including a space character - yes, there is one) would make a poor default, the system chooses an empty string. And since the empty string makes an acceptable default, it will also be an acceptable data value to insert.
I have a question about NULL in database. From my previous knowledge, I can recall my mentor telling me that if the database is indexed and we put NULL keyword in a field then indexing doesnt remain in effect whenever a search is conducted on database and the search is sequential which affects performance significantly (if I am wrong on this concept please correct it). I am working with database currently (DB2) and I notice string 'NULL' instead of keyword NULL. I have tried searching data with string 'NULL' and then same data with NULL and results are different.
I wanted to know the difference between the String 'null' vs NULL
keyword in SQL (DB2)?
is one better than the other?
Does string 'NULL' affect indexing, this goes back to the concept i mentioned
above?
Thanks
I wanted to know the difference between the String 'null' vs NULL keyword in SQL (DB2)?
'NULL' is not the NULL, its a string with a value 'NULL'. Whereas NULL signifies the absence of a value. So if you write a condition like
where column = null //output will be unknown
where column = 'null' //output will contain all rows that have the string 'null'
is one better than the other?
It depends on your requirement. However when you are trying to store NULL then it is not the same as 'NULL'
Does string 'NULL' affect indexing, this goes back to the concept i
mentioned above?
I dont think 'NULL' affects performance. You can cross check it via the stats which you get. See here:
As far as an index is concerned, a NULL is treated like any other
value. (Yeah, I know NULL is really the absense of a value, but index
manager failed the basic relational concepts course ;-)
Given your stats, you won't be able to create a unique index on the
columns since a unique undex will only allow one NULL. With a
non-unique index, all the NULLs will be gathered into a single index
key (with lots of associated RIDs).
I have a table with several columns.
Sometimes some of these column fields may be empty (ie. I won't use them in some cases).
My questions:
Would it be smart to set them to NULL in phpmyadmin?
What does the "NULL" property actually do?
Would I gain anything at all by setting them to NULL?
Is it possible to use a NULL field the same way even though it is set to null?
The concept of the NULL value is a common source of confusion for newcomers to SQL, who often think that NULL is the same as an empty string '', or a value of zero.
This is not the case. Conceptually, NULL means "a missing unknown value" and it is treated somewhat differently from other values. For example, to test for NULL, you cannot use the arithmetic comparison operators such as =, <, or <>.
If you have columns that may contain "a missing unknown value", you have to set them to accept NULLs.
On the other hand, a table with many NULL columns may be indicating that this table needs to be refactored into smaller tables that better describe the entities they represent.
I recommend you read Problems with NULL Values.
1- Would it be smart to set them to
NULL in phpmyadmin?
All fields are null by default unless you specify a default value for them or insert some value for them. No need to do this...
2 -What does the "NULL" property
actually do?
Null means that you have not assigned any value to it.
3- Would I gain anything at all by
setting them to NULL?
As said before, all fields are null by default unless you specify a default value for them or insert some value for them. I don't think you are going to gain anything.
4- Is it possible to use a NULL field
the same way even though it is set to
null?
What would you gain out of a field having value of NULL? No need for this too.
Going to try to answer your questions all at once here.
NULL represents something along the lines of "Unknown"/"No value" or "Not applicable". So yes, if there are columns that are unused in certain circumstances, it would be appropriate to set them to NULL when not used (as no other value is appropriate).
It is possible to constrain a column to NOT NULL, meaning that the column must have a value for each row. An example would the "name" column of a "person" record. It doesn't make sense for a name to be NULL, as everybody has a name.
You can "use" a NULL column, just keep in mind you have to be careful when doing comparisons. A NULL field is never equal to another field. Check for "IS NULL" or "IS NOT NULL".
Brief answers to your questions:
Yes, NULL means that the field contains nothing at all. If that's the true state of affairs, that's what the data should say. An example would be the shipped_date for an order which has not yet shipped. In this case, NULL would accurately represent the value until the order ships out, since until it does there isn't a valid time at which it did (and in this case, checking for the NULL value might be quite a valuable tool in determining which orders do still need to be shipped).
NULL means that the field contains nothing. "Nothing" is different from, say, the value 0 or the string "", as these are values. NULL means roughly the same thing as "N/A" or "I decline to answer". What exactly it would mean is context dependent on the column. Of course, some columns should never be NULL, and you can enforce that with your table design.
If most of the fields in a column are NULL, you should rethink exactly how you're using that column. Generally speaking, a large number of NULL values indicates you could design your tables better. As to defaulting, you can always set a nullable value to default to NULL.
The same way as what? NULL is a unique value. It's not equivalent to 0, or "", or anything else like that. In a query, you must check for IS NULL or IS NOT NULL, and if a null is pulled in to a dataset, you must check for it specifically there too. Asking if a column set to NULL is equal to 0, or "", or what have you, will return false.
Now sometimes some of these column fields may be empty (ie. I wont use them in some cases).
Would it be smart to set them to NULL in phpmyadmin?
Yes, that's what it's for.
What does the "NULL" property actually do?
It makes the database allow NULL as a value stored in the column. "NOT NULL" means a column
must have a value that is not NULL.
Would I gain anything at all by setting them to NULL?
No. If your logic requires that a column never contains NULL as a value, it's better to set it to "NOT NULL". Think of it as an assertion: it is safe to assume the column value will never be NULL, so you don't have to test for it. That database takes care of that assertion.
Is it possible to use a NULL field the same way even though it is set to null?
I'm not sure what you mean by that... Anyway, NULL and NOT NULL columns are identical in every way, except that NULL columns can contain NULL.
And NULL is a strange value. val = NULL is never true, even if val is NULL. For that you have to test with "IsNull()", "IS NULL" or "IS NOT NULL". See Reference Manual: Comparison Functions and Operators.
Due to a weird request, I can't put null in a database if there is no value. I'm wondering what can I put in the store procedure 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?
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. :-(
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...)
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.
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.
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.
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.
What general guidelines should I go by when considering whether I should mark a field 'not null' as opposed to just declaring everything but the primary key null?
Should 'not null' fields have DEFAULT values?
Depends on how you want your application to behave.
First, there will never ever ever be a possible row where this value does NOT contain meaningful data, then use NOT NULL. That is, this value will always be meaningful and represent something.
Do you want the value to always be filled out by the user or programmer in some form or fashion? Use NOT NULL without a DEFAULT
Do you want it to be optional to users and programmers? Use NOT NULL with a DEFAULT
I think you've got 2 questions there:
Should you mark fields as not null?
Yes, assuming that you never intend a valid row to have a null value in that field. Think of "not null" as the easiest type of constraint you can put on a field. Constraints in a database help ensure the data is kept consistent by meeting expectations.
Should not null fields have defaults?
Only when there is an obvious default. For example the Paid field of an invoices table might have a default of 0 (false). In general it works the other way around - if a field has a default value, then it should probably also be not null.
Don't create defaults just for the sake of defaults - if a field should not be null, but there isn't a universal default, then leave it be. That ensures that any INSERT statements must provide a value for that field.
A lot of people look down upon so-called "magic numbers" and would advocate leaving the field as null instead of putting a default down. The only time I ever use default values is when I have a bit field and I just want it to default to false.
Do what is semantically correct.
NULL - does not always exist
NOT NULL - always exists
Try not to define and persist artificial values, like "No value selected" for a drop-down field, or a "No Manager" for an employee's manager.
Whether to use defaults depends on how data gets inserted. If there is a UI with validation, you don't need defaults, IMHO.
Not null fields need to have defaults if they are appropriate especially if you are adding a new field to the table (or changing the field from allowing nulls to not allowing nulls) and you need to give a value to all existing records. However a default is not appropriate or available for all possible fields. For instance, we have a person table, lastname is not allowed to be null. There is no default lastname we could assign though, if the person doesn't have a name, the record doesn't get created. On the other hand, you might have a DateCreated field with a default value of the current date. This is also a field that you would want to have as not null and you would want to make sure that the current date was put in whether the record was inserted from the user interface or from an import or from the query window.