Today is Friday night, so my question is not practical, but of a purely philosophical nature, for fray. Some materials you can probably google, but reluctant to google, I want to talk.

There is such a concept - NULL-values. Meaning: meaning is missing, unknown, does not make sense, etc.

If we are talking about, for example, the date of birth, then the given date is the date of birth, and NULL means that we do not know the date of birth of a citizen. Well, or that he has not yet been born, sits at my mother's stomach.

At the same time, numeric 0 and NULL carry different meaning. If we are talking about, for example, the amount of money in a citizen’s bank accounts, then 0 can mean that he doesn’t have money, and NULL - that we don’t know how much money he has (they haven’t considered it yet).

In many cases, NULL is not applicable. For example, in a bank software in an account about a bank account, the amount is always known for sure - what kind of bank is it if he himself does not know how much money is in the account?

What has been said above has long been known; this was the prelude to the question. And the question is:

If we have a text field, then in what cases does an empty string and NULL carry different meaning?

I thought and could not think of any practically applicable example. It seems that the empty text and NULL in all cases should be considered as equivalents.

If you allow yourself to philosophize a little, then I think the reason is that the text is a very special type, expressing in its most general form the ancient, pre-computer idea of ​​writing. Here we have a clean wax tablet, no damn on it, it's empty. And then we put some style on it and now we have the text. It is easy to see that the “empty text” and “lack of text” do not differ in any way. The text drops out of the "missing" state only when at least one character appears in it.

Here it is appropriate to argue that NULL may indicate the absence of the wax tablet itself, however, returning to the information technologies of the 21st century, I would like to ask: are there any examples where this is necessary?

And what do you think about the equivalence of NULL and the empty string? When does an empty string and NULL carry a different meaning?

Any examples and considerations are interesting.

PS This, of course, is not only about classic SQL DBMS, but about the type and value system as a whole, wherever it is used.

  • NULL is not used in text fields! In the text, NULL will be considered a string whose length is 4 characters. It basically serves to initialize variables. int a; // If the variable "a" is not where the compiler is involved will be cursed. int a = NULL; // and so there will be no swearing - wh1te
  • 2
    Unfortunately, you are mistaken. Here is a question equivalent to what I’ve been asking: stackoverflow.com/questions/3000812/… Here’s a NULL discussion in Oracle, where it’s stated that Oracle has declared the equivalence of NULL and the empty string: habrahabr.ru/post/127327 (yes, I couldn’t help myself Yandex!) - Peter Taran
  • Well, the world of software developers is not only one Oracle, but most manufacturers of compilers do not! It is stupid to rely on the data of one vendor! - wh1te
  • one
    You, probably, thought that I speak about null-oovy pointers and links to objects. And we are talking about a completely different concept. To understand, you probably should get acquainted with this article: ru.wikipedia.org/wiki/NULL_(SQL) - Petr Taran

6 answers 6

Yes, in a bunch of cases, the empty string and NULL can have different meanings.

For example, the text of the instructions. If it is not downloaded (not yet placed in the system) - NULL, and if the text itself is simply missing - an empty string.

And the position of Oracle, too, can be understood. Yet SQL is conceptually a declarative, not a procedural language, so the equivalence of the empty string and NULL can greatly facilitate the lives of developers.

  • How is this an empty instruction text? I have never met instructions with empty text in my life. - Peter Taran
  • If something is not seen, it does not mean that this does not happen. - avp
  • I’m trying to understand: are you rude to me, or you can’t just give an example? - Peter Taran
  • Well, that you, of course not. I just happen to forget that I never wrote the text of the instruction (or something like that). A man opens a file, and there it is empty ... - avp

If we have a text field, then in what cases does an empty string and NULL carry different meaning?

An empty string is a string with no characters. NULL is nothing at all. If we requested a token translation and received an empty string, then the token is not translatable. If we have requested a translation and the result is NULL, it means that no one has bothered with this token, and it’s good to throw an event.

  • Well, that is You are proposing to use NULL as an indicator of an exception. The approach as a whole has the right to life, if an error can happen exactly one. If there can be at least two of them, it is necessary to return information in one form or another about what happened - whether it is an exception, a return code, a special object ... NULL does not look like an adequate solution, so tape to rewind quickly . Why NULL, why not a success / error boolean result? - Peter Taran
  • one
    @Peter Taran, and here and no, it was you who thought up that null is an indicator of an exceptional situation. null is nothing; There is no translation - nothing is returned. This is not necessarily an exceptional situation. - etki
  • Well, that is no translation - NULL, non-translatable token - empty string. In general, yes, there is logic. But, personally for my taste, such an approach is devoid of clarity. For me, it would be better not to distinguish the emptiness / NULL, but to return the additional code that explicitly says: translated as necessary, untranslatable, no translation. It also looks more obvious in the code and can be easily expanded if there are any other situations. - Peter Taran

A very simple example from the life of databases. Database of some hospital.

The middle name field allows for a null state> null <.

We may not know anything about the patronymic of the patient (if he is unconscious and without documents), then it is> null <.

And the patient may not have a middle name according to the documents - well, he is empty in the “father” column. Or he belongs to the nationality, where the middle name does not exist. Then the base is not written> null <, but an empty string - we know that there is a middle name, and we know that it is empty.

    NULL is very convenient as a sign that the variable has no value at all, even an empty one. For example, for organizing memoisation.

    #include <stdio.h> int main(void) { char* txt = NULL; for (int i = 0; i < 10; i++) { if (txt == NULL) { txt = "Hello World!"; } puts(txt); } return 0; }
    • char * txt = ""; What is worse? - Peter Taran
    • 2
      That is quite a valid line. And as we distinguish between two situations: 1. the string variable is not initialized 2. the string variable is initialized with an empty string This can be seen even in my example. Here is the code: if (strlen (txt) == 0) {txt = ""; } makes 10 assignments. Obviously, I chose such a simple code to illustrate the principle. In real life, instead of assignment, there can be a heavy formula, a database query, downloading data from the Internet, etc. etc. That's where terribly slow programs come from ... - VadimTukaev
    • Unfortunately, the principle itself is lost behind the simplicity of the illustration of the principle. Here you just use the feature of storing strings and put emphasis on performance. If we replace char * with std :: string, then there will be no gain, since to distinguish between voids and nulls, std :: string will have to be made dynamic. But performance is the third question. More interestingly, in which cases a meaningful response (heavy formula, database query, downloading data from the Internet) is an empty string. - Peter Taran
    • one
      You are making a common logical mistake. You require proof that "" may be a meaningful response. I do not have to prove it. For me, it is enough that NULL cannot be a meaningful answer (like text). Read - clck.ru/9SsX2 Here is another example, when NULL can be useful, just as yesterday I ran into it when I wrote the function that returns lists (the iterator did not suit). Suppose the function returns strings, lists ... How to understand that they are over? Yes return NULL! The empty string does not fit, it can easily meet where we read. In the file, for example - VadimTukaev

    And what is the distinction between NULL (SQL) and null (null pointer)? Judging by the article, the comparison operations are defined differently. I.e

     NULL == NULL; // возвращает NULL или UNKNOWN null == null; // возвращает `true`

    Hence the philosophical difference for the lines. Two blank lines are the same. Two NULL values ​​are different things.

    If it is necessary to check that two strings (from external data) are equal, it is better to use the concept of empty strings, and not NULL .

    • Well, the incomparability of two NULLs among themselves is all the features of SQL personally. The question is: is one “nichrenanet” to another “nichrenanet” - this is a very deep philosophy, the 37th level, no less! It is more interesting to understand in what situations it is necessary to distinguish the empty string and NULL. - Peter Taran

    When we draw several dozens of parameters from a database and combine them into a single line, it is much easier to save them there beforehand (in the absence of data) as an empty string ("") than later, before merging, check each parameter to ensure that it does not Null Dim fio As String = "Musliev" & "Colabelda" & "" Less fuss with exceptions ...