This discussion is archived
1 4 5 6 7 8 26 Previous Next 385 Replies Latest reply: Aug 20, 2007 5:26 AM by Alessandro Rossi Go to original post RSS
  • 75. Re: Treatment of zero-length strings as NULLs?
    60660 Journeyer
    Currently Being Moderated
    Hi Scott,

    thanks for updating me on MS technology, since I can't (and quite frankly won't) do a test installation on any of my systems (wrong OS). So they finally cought up in that area, good to know.

    C.
  • 76. Re: Treatment of zero-length strings as NULLs?
    60660 Journeyer
    Currently Being Moderated
    DIRTY READS WERE NEVER AN OPTION IN SYBASE. THE
    ISOLATION LEVEL 0 WERE.

    but dirty reads and the isolation level 0 are not
    synonyms.
    My bad, I should have written it like this: "Are dirty reads still a method for developers to bypass some of the limitations in Sybase if they want to avoid certain (dead)lock situations?" Since you did confirm that readers block writers, I'd say that's the case, which somehow contradicts your argument about technical merit. EOD for me.

    C.
  • 77. Re: Treatment of zero-length strings as NULLs?
    William Robertson Oracle ACE
    Currently Being Moderated
    Albert, I wasn't referring to the quotation marks around the words "touched" and "non-touched", I was referring to the definitions of NULL you Re: Treatment of zero-length strings as NULLs? from Wikipedia. I couldn't see the relevance of them to your argument that Oracle's treatment of empty strings is in violation of some alleged industry standard, if that is one of your arguments.

    Are you arguing that Oracle's treatment of empty strings is in violation of some alleged industry standard?

    Were those definitions of NULL intended to show that Oracle has it wrong?

    Possibly you meant to show that the standard definition of a null value differs from your requirement for a known empty value, and therefore demonstrates that Oracle is missing something. Possibly you meant something else.

    I can perfectly understand the benefit of being able to specify "no mobile phone number" as a known fact distinct from "mobile phone number unknown or not required". My own view is that for a minor benefit you get double the complexity because you have two kinds of empty and you need twice as many constraints. What puzzles me is why you think Oracle and anyone who disagrees with you is fundamentally wrong and an idiot.
  • 78. Re: Treatment of zero-length strings as NULLs?
    94799 Explorer
    Currently Being Moderated
    If only someone could, say, knock up a wooden model of NULL in their bedroom or something I'm sure it would explain everything.
  • 79. Re: Treatment of zero-length strings as NULLs?
    William Robertson Oracle ACE
    Currently Being Moderated
    Yes, a simple demonstration of the difference between some zero-length shelving and a missing shelf would help no end at this point.
  • 80. Re: Treatment of zero-length strings as NULLs?
    551707 Newbie
    Currently Being Moderated
    DIRTY READS WERE NEVER AN OPTION IN SYBASE. THE
    ISOLATION LEVEL 0 WERE.

    but dirty reads and the isolation level 0 are not
    synonyms.
    My bad, I should have written it like this: "Are
    dirty reads still a method for developers to bypass
    some of the limitations in Sybase if they want to
    avoid certain (dead)lock situations?" Since you did
    confirm that readers block writers, I'd say that's
    the case, which somehow contradicts your argument
    about technical merit. EOD for me.
    1. The way you ask, and most importantly, what you ask, convinced me that you had never worked with ASE. You might read something about the server here and there, maybe even issue some queries, but you've never worked with Sybase. Am I right?

    2. I confirmed that readers block writers? Forever? And you believed that? No, it was just my New Year's Gift to you. I hope, you enjoyed it. I could also have written it as: "No, now brains block jerks forever", but was afraid you'd never enjoy it.

    For additional fighting go to the forums.sybase.com and say there what you have. This is not the place for it.

    Albert
  • 81. Re: Treatment of zero-length strings as NULLs?
    551707 Newbie
    Currently Being Moderated
    Hey Scott,

    I didn't forget I owed you the answer. But today is Saturday and, as you know, right now begins Saturday Night Fever. Tomorrow is Silvester Night Fever. So, until Tuesday.

    A Happy New Year to you and all members of this interesting forum, specially to those who took part in this thread.

    Albert
  • 82. Re: Treatment of zero-length strings as NULLs?
    60660 Journeyer
    Currently Being Moderated
    I know, I wrote EOD, but one more answer in the old year seems to be fine.
    1. The way you ask, and most importantly, what you
    ask, convinced me that you had never worked with ASE.
    Unfortunately, I had the misfortune of developing with T-SQL.
    You might read something about the server here and
    there, maybe even issue some queries, but you've
    never worked with Sybase. Am I right?
    No, you are not. Other questions in T-SQL could be: Did they introduce array structures after 12.5? Is the text datatype for variables finally supported?
    2. I confirmed that readers block writers? Forever?
    As long as transaction lasts, I'd say.
    And you believed that? No, it was just my New Year's
    Gift to you. I hope, you enjoyed it. I could also
    have written it as: "No, now brains block jerks
    forever", but was afraid you'd never enjoy it.
    I'm afraid I can't follow you. Did Sybase finally change it's transaction model, or not? If not, then what has that got to do with strong wording?
    For additional fighting go to the forums.sybase.com
    and say there what you have. This is not the place
    for it.
    Agreed. So do you have any questions on Oracle topics, or do you want to keep complaining about the differences between the Oracle DBMS and other products?

    Almost forgot: Here's a Re: New Year Wishes the PL/SQL way. ;-)

    C.
  • 83. Re: Treatment of zero-length strings as NULLs?
    537882 Newbie
    Currently Being Moderated
    > Keep in mind, however, that this
    "primitive" ASE 11.0.3.3 was good enough to run
    most
    of Wall Street during the 90's.
    > Maybe, but only to the extend that it ran.

    I accept the extend: IT RAN. Today,
    12.5.1/12.5.3/12.5.4/15.0 run.

    Albert
    Sorry, that should read ?extent? not ?extend?

    It only ran as well as it did, to say. Whereas, is possible it could have run as well as it could have. If you follow. If accepting that this market is leader, then it depends the length of margin which may be better without limitation of Sybase.
  • 84. Re: Treatment of zero-length strings as NULLs?
    537882 Newbie
    Currently Being Moderated
    Now, I must go sleeping and cannot discuss.

    I've already done this. Once again:
    (*) We should all praise our lords that the SQL3
    standard initial draft didn't go ahead allowing
    multiple user defined NULL types.
    User defined NULL types? You really understand
    nothing. User defined NULL types would
    be the negation of NULL, ~NULL or (NOT)NULL that is
    again NULL.


    I'm so sorry. I've read your double-quoted text
    wrong. Too tired. I do apologize.

    Regards

    Albert
    Yes I see you appologise for this already, however I am made this comment in reply to "you understand nothing" in humour only.

    You have not acknowledged the main point of my rebuttal that SQL NULL is not (as you claimed) a fundamental part of either set theory, or relational algebra.

    To reiterate:

    The SQL NULL is not the Empty Set.

    The SQL NULL is not part of relational algebra. SQL NULL requires 3VL and as relational algrebra requires the Law of Excluded Middle, 3VL is out of the question, so you will not find a SQL NULL in relational algebra (or relational calculus.)

    SQL NULL is a SQL adhoc-ism. It's a mistake, and it follows that all implementations are equally mistaken. As soon as you accept 3VL you find you need 4VL (as you have) and it follows that to complete you must consider all possible NULL contexts (there are about 23 as I said earlier)

    Should you (or those writing the ISO SQL rules) decide that this NULL concept can be explored to it's logically correct conclusion then personally I believe the level of complexity foisted upon us as end users of database products does not bear out in the fruits of productivity.

    More so, if you accept to use one product as a professional, you must understand the quirks and live with them.

    Specifically, to try to rationalise one vendor mistake over another is a waste of time.
  • 85. Re: Treatment of zero-length strings as NULLs?
    27876 Newbie
    Currently Being Moderated
    No, no, you were, in fact, discussing the isolation level 0. The link you gave "Dirty reads" is a
    subtitle of "Choosing an isolation level" parent title.
    Well, you can take as many left and right turns in your discussion and dissection of the statement but if you are NOT denying that dirty reads happen (no matter in which isolation level) then your statement that "dirty reads were never and option in sybase" is not correct. Maybe you mean that they were never an option but were rather a necessity in sybase?
    Without the isolation level 0 dirty reads don't exist.
    And hence means you agree dirty reads exist (in which isolation level they exist and in which they do not, is not the question here). The question is simply -

    "Do they or do they not exist in that product?"

    Again, I was just quoting the link where dirty reads is the topic of discussion. The link talks about dirty reads. It does NOT matter it is subtitle of something or not. I'm not discussing any isolation level. I just posted the link and quoted few lines from the link (not my words or my discussion, if that is what you mean when you say "I were discussing isolation level").
  • 86. Re: Treatment of zero-length strings as NULLs?
    hans forbrich Oracle ACE Director
    Currently Being Moderated
    not have been any need for all this argument. Why MS
    Varchar and Oracle Varchar2 in the first place if
    they are not going to mean the same. The issue about
    Actually, many, many moons ago, Oracle create varchar2 to distinguish from IBM's varchar datatype. The IBM definition was embedded in an ANSI standard and that was the reason for Oracle creating varchar2. (At least that was what Oracle developer and PM told me at the time - mid 80's). No idea how Sybase (and it's spawn, MS SQL Server) handle varchar in comparison to the IBM definition.

    The docco in Oracle 5 and 6 explicitly stated the difference. (The difference is in comparison semantics - indicating whether shorter strings get padded to perform the comparison.)

    Besides - is there any RDBMS out there that is truly and fully ANSI SQL compliant? To any version of ANSI SQL? <g>

    Just like any other tool, you simply gotta learn the tool and know how to work around the shortcomings.
  • 87. Re: Treatment of zero-length strings as NULLs?
    William Robertson Oracle ACE
    Currently Being Moderated
    > The docco in Oracle 5 and 6 explicitly stated the difference. (The difference is in comparison
    semantics - indicating whether shorter strings get padded to perform the comparison.)

    Surely VARCHAR and VARCHAR2 were new in 7.0 (1991), along with the blank-padded CHAR type. Previously VARCHAR was a synonym for CHAR, which used to be a variable-length string with a maximum length of 255 bytes. Every version of the documentation since then has explained the difference.
  • 88. Re: Treatment of zero-length strings as NULLs?
    hans forbrich Oracle ACE Director
    Currently Being Moderated
    You are right ... I should have looked it up rather than relying on memory of something I haven't used in a dozen years.

    So I did look it up and the Oracle 6 DBA guide, page 6-2 states CHAR and VARCHAR are the same.

    The difference was, as you say, introduced in Oracle 7
  • 89. Re: Treatment of zero-length strings as NULLs?
    553985 Explorer
    Currently Being Moderated
    Although null values frequently cause problems in data retrievals, they can sometimes be used to increase performance.

    Consider the case of a very large table (20,000,000 rows) to which new records are added daily (usually about 1,000 of them). Every night, you need to report these additions on an audit trail. Rather than scan the whole table looking for changes, you will want to use an index over the TRANSACTION_DATE column. But the index would need to be huge. This is a case in which your index is over the entire table, although you are actually interested only in the 1,000 or so records that were added today. The actual index is physically many times larger than it needs to be, and it uses many more disk I/Os to traverse the binary tree to the leaf data.

    Now suppose you add a smaller (one-character) column to the table. This column distinguishes between the records that need to be printed and the records that do not need be printed; the column would contain "U" for unprinted and "P" for printed. This gives you a good way to find the records you are looking for. Although the index isn't as large as was required in the previous example, it still contains 20,000,000 entries. All this just to find the 1,000 that you need to print.

    By taking advantage of the special qualities of null, you can avoid having to store and maintain all of these index entries. When the print job actually prints the new records, it prints each record containing a "U" flag. Once the record has printed successfully, the print routine resets this column to null, thus removing all references to those unprinted (and not new) records from the index. The index will never grow any larger than the approximately 1,000 records you have added today. By doing this, you reduce the expected size of the index from approximately 20 megabytes to 20 kilobytes. The reduction in size easily justifies the additional overhead (a new subindex and an extra column update) associated with it.
1 4 5 6 7 8 26 Previous Next