Re: Strange Wierdness with SQLServer Bit fields and SQLProvider

Thanks so much Frans for that tedious work of weaving the two arguments
together (Mine and Marc's ) and adding your view.

And, Marc, when I saw your list of accomplishments in your last post, I
said, "This guy is more experienced than he sounds. Why doesn't he get it?"
Alright, to level the play field, I'll just send you to a google search of
me: "Peter Obiefuna". If you search "Peter c.m. obiefuna" you'll probably
see my scientific research published in various journals. I, too, made my
bones in a world where people die when mistakes happen ... and my null
didn't kill no one.

And while you were busy writing laboratory software, I was busy writing
embedded system that streamed the laboratory equipment into computer memory
(the system you would have dependeded on as if sent to you from heaven). And
in that world, I used the equivalent of a null as an elegant indicator that,
for instance, a cache query on my little logic board is a hit or a miss
before I look in conventional memory.

<joke> And following Marc's law, if you see that I am a 'Dr', it means I
paid lot and lots of fees! That should still buy me some consideration.
</joke>

On a serious note: The moral in this interchange between Marc and myself is
that being enormously successful can lead one to still end up like some:
become over-prescriptive, scoff as 'evil' anything that you didn't like or
was out of your reach or over your head even in your hay day ... and
intimidate junior colleagues, poking holes in all their decisions ... your
colleagues come to the community forum with a problem, you don't suggest a
solution to them, you start picking unrelated holes in their system and
using your narrow worldview as law. It's easy to upgrade your chance success
to silver-bullet status. Apparently, that can happen to even the eminent
ones among us.

By the way, Marc, three of the above paragraphs are null (I just used what
you can now see as default magic values). Am sure you can figure out which
ones. I have 3 other paragraphs that I just allowed to remain null (by the
aid of my backspace key). Which of the representations of null do you
prefer?
P


--------------------------------------------------
From: "Frans Bouma" <[email protected]>
Sent: Wednesday, November 28, 2007 1:18 AM
To: <[email protected]>
Subject: Re: [DOTNET-CLR] Strange Wierdness with SQLServer Bit fields and
SQLProvider

>> > Admittedly, null may act weird sometime.
>>
>> NULL acts wierd ALL the time... how else can you talk about something
>> that is simultaneously equal AND not-equal to itself (see NaN in IEEE
>> float formats for another edge-case waiting to bite you).
>
>        A magic value won't help you in a lot of cases. take a varchar(10)
> field. You can't say "" is the undefined value, because that's for example
> a valid value. So you need a value for undefined. That's why NULL is a
> valid value in the database and people who seek to get rid of NULL values
> will sooner or later run into the magic value hell they created
> themselves.
>
>> > If you loose null, you loose lots of things that null enables in
>> > advanced
>> > designing.
>>
>> Seriously, NULL is considered anathema in SQL databases by one of the
>> INVENTORS of SQL.  Chris Date (of Date & Cobb) fame considers NULL in
>> databases to be "inherently flawed".  The other guy (E.F. Date), who
>> supports NULL considers the current NULL to be "completely inadequate"
>> and suggest that you need TWO NULLs to indicate whether something is
>> "missing but applicable" or "missing but NOT applicable".  The fact
>> that the two guys that started the whole mess don't agree that it
>> should be there, and that the one that says it should argues that it's
>> not right as-is tells me something. [0]
>
>        If they don't agree to have null values, why is null a fundamental
> value in SQL? SQL is a standard, and NULL values are part of that. That's
> not cooked up by some college kid, but by people who understand the value
> of NULL.
>
>        Having an entity instance field set to NULL has just 1 meaning: the
> value is undefined. That's the state of the entity at time T. There's no
> 'missing but not applicable', the state is just 'undefined' for that
> field. It's up to the rest of the relational model to allow that or not.
> If you don't allow that, NULL values aren't for you.
>
>        The missing but not applicable only occurs in situations with
> cycles in the relational model (entity X and Y have an FK to each other),
> something which is considered a flawed model anyway.
>
>> > A practical application is that Null let's you have optional
>> > foreign/unique
>> > keys.
>>
>> So every query, every application needs to handle the what-if the
>> foreign-key value is missing?  So every INNER JOIN gets turned into a
>> LEFT JOIN and thus all the other columns in that joined-to table must
>> be special-cased to handle the missing related record... joy.
>
>        INNER joins are staying INNER joins: it's the operation to obtain
> the set of entity instances which have a non-null FK together with their
> PK side.
>
>        An undefined FK field means just that: the FK is undefined, which
> means the relationship isn't mandatory. If the relationship IS mandatory,
> you can't have a nullable FK. It's as simple as that.
>
>        So, you on the other hand will create a non-nullable FK and also a
> flag which signals if that flag is null or not, and you together with that
> can't create an FK constraint, because you have to use a magic value for
> the non-nullable FK field in the case it's undefined.
>
>        I.o.w.: you're re-building an RDBMS system inside SQL. Newsflash:
> that's already been done for you :)
>
>> > So much so that Microsoft had to yield to the practical pressure to
>> > bubble
>> > nullity into the  .NET  valueType space
>>
>> They bent to the will of people that wanted to deal with database
>> nulls, but not the elegence of design... which is why we now have to
>> litter our code with lovely constructs like:
>>
>> string ownerName = record.owner.HasValue() ? record.owner.name :
>> string.Empty;
>>
>> Sexy!!!
>
>        perhaps you should look up the types which are nullable first
> before bashing it. If owner is a valuetype, what's 'Name' ?
>
>> > not intended for storing crazy stuff in the database, otherwise, all
>> > types
>> > may need to be reduced to some magic value. Magic values are a poor
>> > replacement for 'nothingness', probably because the magic value in the
>> > first
>> > place is not a type of 'nothingness'.
>>
>> As indeed is NULL.  It's an out-of-band special value, to be sure, but
>> it IS still a special value, and is a poor substitute for _why_ the
>> value is not there... an enumeration is far my useful for this...
>
>        Murphy's law on magic values: There comes a day when you need to
> store the value which you declared the magic value, as a true value in
> that field.
>
>> > These are personal opinions,
>> > however, and am sure that there are cuter opinions out there. The
>> > cutest of
>> > it all for me is that null unifies everything for all types, meaning
>> > one
>> > thing and only one thing: no value is appropriate because in there's no
>> > place for this thing in the space of all possible members of the
>> > alphabet of
>> > this set.
>>
>> Cute isn't the issue, nor it NULL unifying. In fact, it's exactly the
>> opposite.  You cannot say two NULLs are the same... they aren't.  NULL
>> represents discontinuity more than unity.  Your dismissal of the use
>> of it is a clear indicator of someone that hasn't _actually used it_.
>>  Much like those that dismiss TDD as too much work don't have the
>> practice to see where it saves so much.
>
>        oh cut the crap, please. NULL means not defined. End of story. I'm
> sure the boys over at ISO have a nice thick document attached to the SQL
> standard about NULL values.
>
>> > And anytime you set a magic value with the magical powers of indicating
>> > a
>> > loss of existence.
>>
>> I never advocated a magic number.  I said that the NullObject pattern
>> should be used when appropriate, and that you shoud use a flag or
>> enumeration when it is important to capture WHY something is
>> missing/not-used/not-valid... this is something NULL can't do. Ever.
>
>        the 'why' can't be included in the data. A NULL value follows from
> optional values. That's the whole story. Draw a NIAM diagram and define
> optional attributes and relationships. The optional relationships and
> attributes will create nullable entity fields in your DB. This is simple
> and effective because the state at any given time T for an entity is only
> defined by its instance, which is the data. You might THINK you should
> store why field ABC is undefined, but that's only valid for a given time
> T. At time T+t, this reason is void, and you have to update your reason in
> the db.
>
>> > No doubt, the null enigma needs some taming ...
>>
>> Part of that taming is in understand where it is broken.  Part of that
>> is understanding the true implications of your design's decisions.
>>
>> Guess how many null-checks my social-network site's code needs?  None.
>>  Any idea how much faster that is? I do, I've benchmarked it.
>
>        My code has 1 null check. Oh boy, it takes a very very small
> portion of the time it takes to read a rowset from a database server on
> the network!!!111
>
>        So your code is significantly faster because you weeded out the
> nullchecks and that's provable with a benchmark, even though
> roundtripping, query execution etc. is much slower than your null check
> will ever be? Interesting.
>
>        Did you also benchmark the time you have spend on fixing all the
> bugs in your parallel FK constraint code to make things fail proof?
>
>> Guess how many places I have to code the behavior of a unowned profile?
>> One.
>
>        whoa, you are really good, Marc!
>
>> Guess how many places I have to enable localization of that entity?
>> Two (gotcha!) one in the code and one in the view that is used for
>> reporting (and PLEASE tell me that you don't code reports against the
>> actual table.... please?!?)
>
>        You do know what views do at runtime, Marc? That if you don't use
> indexed views, it's for performance reasons not useful to use views ?
>
>> > Well, then, maybe that's why it takes a  college degree before people
>> > get
>> > unleashed to go trying these kinds of stuff on their own.
>>
>> If only computer science was like that... hell, that wouldn't help...
>> one of the smartest coders I know, with a CS Masters, didn't know
>> until instructed by me why clustered indexes were good, why UPDATE
>> statements can READ data, and why you don't put BIT values in
>> indexes... college degrees mean you paid the tution and (maybe)
>> attended some classes...
>
>        ah, so your friend proves that CS degrees suck bigtime, you should
> learn it in practise!
>
>        I suddenly understand your post. ;)
>
>                FB
>
> ===================================
> This list is hosted by DevelopMentor  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com