Please create a I Hate Microsoft Club too

[LB_]

@RaceProUK I think Mozilla was trying to make their own Chromebook equivalent at some point, though, unlike Microsoft/Edge.

[darkmatter]

@masonwheeler said in Please create a I Hate Microsoft Club too:

for why it's a bad thing. A lot of semantic tautologies that boil down to "they're different things and should be represented differently!!!", but no actual logic.

Yes in many applications null vs empty may not matter to you. But there are applications where it matters. In my particular area, data warehousing, the lack of ability to actually put an empty string prevents me from being able to discern between "this is empty because we wanted it to be", and "this is empty because we didn't have any data". On Oracle in order to tell what the fuck the real answer is, some string fields we have actually have to resort to storing some dumb known impossible string like, 'THIS IS EMPTY BECAUSE WE WANT IT TO BE' that we translate out in the application to empty so you can tell the difference.

I'd store 'UNKNOWN' for the ones where the data is missing, except what if you have a field where the value really could be literally the string 'UNKNOWN'?

[darkmatter]

@RaceProUK said in Please create a I Hate Microsoft Club too:

There's a massive difference between I know this is an empty string and I don't know what this string is

fucker, that's a lot shorter way of saying what i did.

[darkmatter]

@masonwheeler said in Please create a I Hate Microsoft Club too:

Mason NULL Wheeler

yeah, and I'm glad I can tell that Mason Wheeler FORGOT TO FILL HIS MIDDLE NAME IN, not that he actually has no middle name (I don't).

[darkmatter]

@masonwheeler said in Please create a I Hate Microsoft Club too:

I'm deliberately pointing out that there are a lot of contexts in which your proposed solution makes no sense. If you find that demonstration annoying, well... that should tell you something.

and i'll point out to you that you need to learn some things about databases and their usages - making it annoyingly impossible to differentiate NULL and '' without hacky workarounds just becomes sometimes it's okay is the dumbest reason ever for fucking shit up.

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

Aside from SQL null handling rules, it's never really made a difference for me in practice.

this is also another good point.

 select * from table where field = '' 

is what a normal person searches for in, well, every database except fucktarded oracle, where you have to do

 select * from table where field is null

[powerlord]

@wharrgarbl said in Please create a I Hate Microsoft Club too:

The oracle one is unnecessary and I think it was created because the site owners hate Oracle more than the other corporations.

Everything Oracle touches turns to shit. As hard as it is to believe, there are some things Microsoft does well.

[Arantor]

Then you have http://www.nullmedia.com whose founder is Christopher Null and whose email address at one time was null at that domain. So many services couldn't handle it.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

In my particular area, data warehousing, the lack of ability to actually put an empty string prevents me from being able to discern between "this is empty because we wanted it to be", and "this is empty because we didn't have any data". On Oracle in order to tell what the fuck the real answer is, some string fields we have actually have to resort to storing some dumb known impossible string like, 'THIS IS EMPTY BECAUSE WE WANT IT TO BE' that we translate out in the application to empty so you can tell the difference.

I doubt I'd trust that distinction. How does a user enter an empty string?

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

How does a user enter an empty string?

It's not necessarily about the users' data entry. I'm pulling various pieces of information from disparate sources and stitching it all together. So I'll have columns coming from sources X, Y, and Z. Sometimes Y doesn't exist for a certain data point. I want the fields from Y to be NULL - then I know Y did not exist. But maybe Y did exist and the fields actually had empty strings... then I'd rather it is '' so I know I got the data from Y. In Oracle, I'd have NFC whether source Y came in or not unless I handle empty strings or nulls in a special manner to differentiate.

@Arantor said in Please create a I Hate Microsoft Club too:

So many services couldn't handle it.

That's because you were using PHP without parameterized queries ;)

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

It's not necessarily about the users' data entry. I'm pulling various pieces of information from disparate sources and stitching it all together. So I'll have columns coming from sources X, Y, and Z. Sometimes Y doesn't exist for a certain data point. I want the fields from Y to be NULL - then I know Y did not exist. But maybe Y did exist and the fields actually had empty strings... then I'd rather it is '' so I know I got the data from Y. In Oracle, I'd have NFC whether source Y came in or not unless I handle empty strings or nulls in a special manner to differentiate.

OK, well...then from wherever. I think this business of using empty strings to mean something is pretty bogus and relying on it is because you're assuming things that aren't really implied by the evidence.

Your XYZ example isn't any different than what I said about not trusting users. You just pushed it down a level. How did source Y get empty strings entered into it?

Everyone always talks about this, but the more I think about it the less sense it makes.

[Jaloopa]

@boomzilla it's the difference between an outer join showing a match with no data, and no match at all. They could mean very different things

[boomzilla]

@Jaloopa said in Please create a I Hate Microsoft Club too:

@boomzilla it's the difference between an outer join showing a match with no data, and no match at all. They could mean very different things

No, now you're doing the same thing as @darkmatter and pushing it to another table instead of another system. How do you distinguish, "user skipped this field" from "user entered 'empty string'"?

Or (to make a better outer join analogy)...user clicked the "Add foo" button and then didn't enter anything into the foo form but clicked save?

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

How did source Y get empty strings entered into it?
Everyone always talks about this, but the more I think about it the less sense it makes.

eh? For a specific example Source Y in one of my system's data has empty strings because it's a spacer line on an output (in the original system we pulled it from). On the data warehouse it is a dimension attribute for searching over. It could be a description, it could be an empty line, or it could be a record that came from one system and not the other which ends up being NULL. We'd prefer to know when that happens. With Empty->NULL, we have no way to tell natively. I'm not pushing anything anywhere, I am literally talking about specific instances in my data that i know are supposed to be empty strings and not nulls. If i had a null, I'd know something fcked up. In Oracle, i'd have no idea unless I write a handler for it.

I know this because we converted from Oracle to a different system. I am the one that did the conversion. I know of specific places where routines actually still do retarded "THIS IS EMPTY BECAUSE WE WANT IT TO BE" handling on strings even though it's not necessary on the new database, because now there are reports that rely on those dumb things and we didn't feel like going back through and updating all the reports too. I'm not just theorycrafting circumstances, these are real situations I really dealt with.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

it's a spacer line on an output

What does that mean?

@darkmatter said in Please create a I Hate Microsoft Club too:

I'm not just theorycrafting circumstances, these are real situations I really dealt with.

OK, but you're still not answering my question. How did the users identify "empty string" in the first place?

[Arantor]

@darkmatter pfft, I use a DB that can handle it just fine and I was doing it sanely before we had PDO or mysqli.

[PleegWat]

@darkmatter Right. So '' IS NOT NULL is useful if there are exactly two reasons for you not to have a value. However, if a third reason arises you end up needing a reason field anyway, and your code gets all the messier because you identified the first two reasons with the '' vs NULL distinction.

[djls45]

@masonwheeler said in Please create a I Hate Microsoft Club too:

@RaceProUK There's this guy out there named Mason NULL Wheeler who thinks there might be an obvious problem or two with that idea...

If this is a problem, it is a problem with your application's handling of strings; it is not a problem with the database's storage methods.

[djls45]

@anonymous234 said in Please create a I Hate Microsoft Club too:

@Jaloopa said in Please create a I Hate Microsoft Club too:

@Luhmann said in Please create a I Hate Microsoft Club too:

@Onyx
I think we might be needing a "I hate Chromebooks" section too

FTFBL

Hatters gonna hat!

FTFBL again

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

How did the users identify "empty string" in the first place?

I think I don't understand your question. They identify "empty string" as an empty string. ie, field = '' in some report builder autogenerated search.
In oracle, the report builder would have to translate to field is null or else it would retrieve no records because nothing = NULL. If it translates to field is null, then it pulls back all the undefined records along with the ones they wanted. Both of those are wrong.

[djls45]

@Yamikuronue said in Please create a I Hate Microsoft Club too:

@RaceProUK NULL is a bad one here, because your end users won't know the difference. Something like unknown set off in a different font or color (maybe a light grey instead of black) to show that it's different than entering the word unknown would be best.

You mean like this?

This is a null stringvalue and an empty string in an MS SQL Server database (zoomed in for emphasis).

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

I think I don't understand your question.

I agree.

@darkmatter said in Please create a I Hate Microsoft Club too:

They identify "empty string" as an empty string. ie, field = '' in some report builder autogenerated search.
In oracle, the report builder would have to translate to field is null or else it would retrieve no records because nothing = NULL. If it translates to field is null, then it pulls back all the undefined records along with the ones they wanted. Both of those are wrong.

But I'm talking about the data they're looking at and reporting upon. How did those empty strings get in there in the first place? As opposed to the nulls.

[djls45]

@TimeBandit said in Please create a I Hate Microsoft Club too:

@Dragnslcr said in Please create a I Hate Microsoft Club too:

But if I know you don't have an email address, I won't keep asking you to provide it.

Even if I have an email address, and you keep asking me to provide it, I may choose to answer NULL

In which case, the system will store "NULL" instead of NULL, because it's properly handling text input.
(And the validator will reject it as an invalid email anyways.)

[darkmatter]

@darkmatter last week we needed to check for the groupings on a set of items that had been added. Some of them are in no group, which is ''. Some of them are in groups, say 'Test Set' Some of them had not yet been added by the users on the other system, which meant their group was NULL. We needed to find the ones that had not been set up yet - hence, searching for NULL. In Oracle we'd have kept getting the '' empty groups showing up as having not been set up yet, unless they want to add a meaningless 'THIS ITEM HAS NO F`IN GROUP' to the data.

[djls45]

@darkmatter said in Please create a I Hate Microsoft Club too:

@boomzilla said in Please create a I Hate Microsoft Club too:

Aside from SQL null handling rules, it's never really made a difference for me in practice.

this is also another good point.

 select * from table where field = '' 

is what a normal person searches for in, well, every database except fucktarded oracle, where you have to do

 select * from table where field is null

Unless you are specifically searching for data that hasn't been entered yet vs. data that is entered as empty, in which case the second query is correct. And, as has been mentioned multiple times already, Oracle conflates these two use cases.

[djls45]

@boomzilla said in Please create a I Hate Microsoft Club too:

@Jaloopa said in Please create a I Hate Microsoft Club too:

@boomzilla it's the difference between an outer join showing a match with no data, and no match at all. They could mean very different things

No, now you're doing the same thing as @darkmatter and pushing it to another table instead of another system. How do you distinguish, "user skipped this field" from "user entered 'empty string'"?

Or (to make a better outer join analogy)...user clicked the "Add foo" button and then didn't enter anything into the foo form but clicked save?

The difference is that they clicked "Add foo" and "Save" instead of not clicking "Add foo" in the first place.

[darkmatter]

@djls45 said in Please create a I Hate Microsoft Club too:

Unless you are specifically searching for data that hasn't been entered yet vs. data that is entered as empty,

Yeah that's my exact point. in our data warehouse the data comes from many disparate systems which may or may not all be updated to align with each other. My job is cleaning that garbage and possibly reporting on what's missing. We do have fields where there is an empty string intentionally. We do have fields where empty string is a valid value that also might not have any data because the originating system didn't have that item. In Oracle there is no way to tell the difference without placeholders. It is annoyingly stupid.

Arguing that we shouldn't have empty string data is not an argument. We Have Empty String Data. That is a fact. Oracle can't handle it. That is a fact.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

@darkmatter last week we needed to check for the groupings on a set of items that had been added. Some of them are in no group, which is ''. Some of them are in groups, say 'Test Set' Some of them had not yet been added by the users on the other system, which meant their group was NULL. We needed to find the ones that had not been set up yet - hence, searching for NULL. In Oracle we'd have kept getting the '' empty groups showing up as having not been set up yet, unless they want to add a meaningless 'THIS ITEM HAS NO F`IN GROUP' to the data.

Ah, so this is an artifact of how you're transforming data from multiple systems and relying on the implementation of strings in the database to tell you something. Yeah, I still think this is . Don't get me wrong, I pull equivalent stunts of relying on implementation details all the time, and they often come back to bite me later, too.

[boomzilla]

@djls45 said in Please create a I Hate Microsoft Club too:

@boomzilla said in Please create a I Hate Microsoft Club too:

@Jaloopa said in Please create a I Hate Microsoft Club too:

@boomzilla it's the difference between an outer join showing a match with no data, and no match at all. They could mean very different things

No, now you're doing the same thing as @darkmatter and pushing it to another table instead of another system. How do you distinguish, "user skipped this field" from "user entered 'empty string'"?

Or (to make a better outer join analogy)...user clicked the "Add foo" button and then didn't enter anything into the foo form but clicked save?

The difference is that they clicked "Add foo" and "Save" instead of not clicking "Add foo" in the first place.

Yes, you're just repeating what I said without addressing the problem.

[LB_]

@boomzilla said in Please create a I Hate Microsoft Club too:

How does a user enter an empty string?

User enters empty string by leaving field blank when submitting the form.
User enters null by that field having never existed when they created their account and refusing to ever submit the form with the new field.

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

Yeah, I still think this is .

So pray tell, what exactly should be in the data to tell me there was no data? Insert a keyphrase that can't possibly be anything but meaning there was no data?
'FIELD_DATA_NOT_FOUND'?

That's one way to do it... But Oracle is the only database crappy enough to actually require that you put a hardcoded string in to represent missing information.

[darkmatter]

@darkmatter it's not like it's an extremely common situation - but it just makes no sense to me that a database would make UNKNOWN = EMPTY. That's not true in hardly any other language without coercion and/or weak typing, or languages where you have no real NULL and have to wire it to 0.

 c=null;
 b='';
 b===c;
 >false

 c=null;
 b='';
 b==c;
 >false

[djls45]

@boomzilla said in Please create a I Hate Microsoft Club too:

@djls45 said in Please create a I Hate Microsoft Club too:

@boomzilla said in Please create a I Hate Microsoft Club too:

@Jaloopa said in Please create a I Hate Microsoft Club too:

@boomzilla it's the difference between an outer join showing a match with no data, and no match at all. They could mean very different things

No, now you're doing the same thing as @darkmatter and pushing it to another table instead of another system. How do you distinguish, "user skipped this field" from "user entered 'empty string'"?

Or (to make a better outer join analogy)...user clicked the "Add foo" button and then didn't enter anything into the foo form but clicked save?

The difference is that they clicked "Add foo" and "Save" instead of not clicking "Add foo" in the first place.

Yes, you're just repeating what I said without addressing the problem.

You're asking the database to solve a form entry issue. If the form is submitted without data, the form was still submitted. Having nulls be different than empty string allows the system to be greatly simplified and prevents a need for even more fields to differentiate non-entry from empty entry.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

So pray tell, what exactly should be in the data to tell me there was no data? Insert a keyphrase that can't possibly be anything but meaning there was no data?

Some other field to indicate that there's a difference. I'm assuming that you're condensing the data from the two systems into a single piece of data. How do you handle when the two sources have conflicting information?

@darkmatter said in Please create a I Hate Microsoft Club too:

That's one way to do it... But Oracle is the only database crappy enough to actually require that you put a hardcoded string in to represent missing information.

Sure, sure. Or it's the only one that doesn't let you get lazy and rely on implementation details and using dangerous inferences from it.

[Arantor]

@boomzilla except it's not a dangerous inference.

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

I'm assuming that you're condensing the data from the two systems into a single piece of data. How do you handle when the two sources have conflicting information?

Not condensing into the same field.
Your suggestion is that for every field from every source I have a corresponding 'Y', 'N', 'FILE_NOT_FOUND' field so you can tell the difference between NULL and ''?

The "implementation detail" that I'm relying on is the ANSI SQL standard. If they want to change 2+2 from 4 to 5 then all the programs that need it to equal 4 will indeed be screwed up.

[boomzilla]

@djls45 said in Please create a I Hate Microsoft Club too:

You're asking the database to solve a form entry issue.

Not at all. I'm asking how you solve the form entry issue.

@djls45 said in Please create a I Hate Microsoft Club too:

If the form is submitted without data, the form was still submitted. Having nulls be different than empty string allows the system to be greatly simplified and prevents a need for even more fields to differentiate non-entry from empty entry.

And so you'll never know when someone doesn't have a middle name vs someone who didn't tell you about the name. Which is my point. Why are you trusting this empty string vs null string thing?

Having that extra field would imply that the user is clicking something to indicate This field intentionally left blank. But I don't see how you can reasonably infer that otherwise. And I don't recall seeing this sort of thing in regular use.

Do all the Oracle-null-empty-string-haters put those in all of their forms with optional data?

[darkmatter]

@boomzilla meh. the bottom line is that NULLhas a meaning, and it is not ''. Making them the same is quite simply stupid.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

Your suggestion is that for every field from every source I have a corresponding 'Y', 'N', 'FILE_NOT_FOUND' field so you can tell the difference between NULL and ''?

What? No. OK, I'm probably misunderstanding your example, but I'll be more explicit as to what I'm thinking here:

System X
Users set up Foo and put it into whatever groups.

System Y
Users never set up Foo.

Data warehouse
There is a Foo record and records about groups. The Foo record does not indicate if it comes from X or Y or both.

How do you detect when there is no Foo in Y? How do you detect if users put the groups differently in the different systems? I think these questions lead to an answer of how to be explicit about when Foo isn't set up in Y without resorting to inferring things from empty strings.

[darkmatter]

@darkmatter said in Please create a I Hate Microsoft Club too:

Making them the same is quite simply stupid.

In 100% of languages with a SQL interface, when you pull NULL and '' out of the database into their respective language types, they will not be equal. Except in shittastic Oracle, where they are both NULL for no good reason.

[boomzilla]

@Arantor said in Please create a I Hate Microsoft Club too:

@boomzilla except it's not a dangerous inference.

Why not? How do you know the user meant to put in a NULL vs an empty string?

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

@darkmatter said in Please create a I Hate Microsoft Club too:

Making them the same is quite simply stupid.

In 100% of languages with a SQL interface, when you pull NULL and '' out of the database into their respective language types, they will not be equal. Except in shittastic Oracle, where they are both NULL for no good reason.

Look, I agree that it's weird from a language / technical / OCD perspective, but I don't think it's important like everyone is saying with their middle name example.

Yours is a bit different, since you're importing and transforming data. But I don't see it as that big a deal, either, in practice, except that you've come to rely on it and it's a PITA to convert to something else, just like if you made assumptions about, say, pointer sizes in C.

[darkmatter]

@boomzilla
We started with Oracle. What we have is not a "thing we rely on", it was a motherfcking problem that arose because of Oracle. We have now moved and that dumb issue is no longer a problem (except on the old migrated data where we got all NULLs because Oracle is a piece of shit.

i find it very funny that you're arguing against an existing use case. I'm not even having to make up any examples, all I'm having to do is try to make the data anonymous and shortened enough that i dont quite have to type a novel about it.

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

I think these questions lead to an answer of how to be explicit about when Foo isn't set up in Y without resorting to inferring things from empty strings.

I could relate to how adding a field so that when you query you have to ask

 system_y_had_data = 'Y' and system_y_data is NULL 

to get a simple ''

Sure, that's one way of doing it.
One long and protracted way that still requires you to convert the NULLto a '' after you retrieve the record because Oracle has no way of transmitting a ''

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

i find it very funny that you're arguing against an existing use case. I'm not even having to make up any examples, all I'm having to do is try to make the data anonymous and shortened enough that i dont quite have to type a novel about it.

It's obviously difficult with the details being so vague. I'm trying to understand the use case, but applying my well earned skepticism of data to what I'm reading. Your case is not as obviously silly as the people insisting how important it is to know whether someone has no middle name or not is going to indicate that in their application (as opposed to skipping an optional field in a form for any number of reasons).

@darkmatter said in Please create a I Hate Microsoft Club too:

I could relate to how adding a field so that when you query you have to ask

I dunno...I don't understand why you're having to add a field, except as an artifact of your transformation / merge process. And you're still avoiding the question about how you handle conflicting data, which is really what this seems to be.

[darkmatter]

@boomzilla said in Please create a I Hate Microsoft Club too:

how you handle conflicting data, which is really what this seems to be.

I'm totally lost on your insistence that 2 columns with 1 from source X and 1 from source Y would make a conflict.

 Source X = 'data' -> column 1
 Source Y = '' -> column 2

no conflict. the issue is when

 Source X = 'data' -> column 1
          -> column 2

In oracle, both of those are identical outcomes, a NULL in column 2.

In a real database, column 2 would have '' in one case, and NULL in another, and it would be obvious that there was no input from Source Y.

In oracle, I would have to either stuff some data into the '' to let me know it was empty and not non-existent. Or I'd have to add a column like I said above, to flag whether or not Source Y's data existed.

[boomzilla]

@darkmatter said in Please create a I Hate Microsoft Club too:

@boomzilla said in Please create a I Hate Microsoft Club too:

how you handle conflicting data, which is really what this seems to be.

I'm totally lost on your insistence that 2 columns with 1 from source X and 1 from source Y would make a conflict.

 Source X = 'data' -> column 1
 Source Y = '' -> column 2

no conflict. the issue is when

 Source X = 'data' -> column 1
          -> column 2

In oracle, both of those are identical outcomes, a NULL in column 2.

In a real database, column 2 would have '' in one case, and NULL in another, and it would be obvious that there was no input from Source Y.

In oracle, I would have to either stuff some data into the '' to let me know it was empty and not non-existent. Or I'd have to add a column like I said above, to flag whether or not Source Y's data existed.

I'm not following you at all, I'm afraid. Are columns 1 and 2 from X and Y, respectively supposed to be the same thing? I would have called them column 1 in both, in that case. Sorry, this has just confused me more.

Also, from your initial example, I got the impression that these things were relations in X and Y, not just free text fields.

[darkmatter]

@boomzilla they're not the same thing. All of the sources have different information.
Like Source X may contain Location information about Businesses while Source Y contains Employment information. I'd be merging the 2 into a single extremely wide table with 1 record per business and however many dozen columns of identifying information about the business.

[Groaner]

I love how this turned into an I Hate Oracle thread.

On topic: if you're going to make a category for complaining about Microsoft, go read The Old New Thing for about a year or so. If after reading about all the stupid crap they have to support you still have a negative opinion, then go ahead.

On the other hand, I'm not going to defend SSIS imports of spreadsheet data where the first 10 rows are analyzed and then the 11th row (containing valid data) is rejected because it doesn't match the deduced data type of the first 10.

[Arantor]

@Groaner it's still on topic, because it demonstrates that MS have a long, long way to go before sufficiently evil to deserve a category for the hall of shame and infamy.