Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 9845 invoked from network); 12 Jul 2007 19:20:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Jul 2007 19:20:27 -0000 Received: (qmail 35208 invoked by uid 500); 12 Jul 2007 19:20:28 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 35173 invoked by uid 500); 12 Jul 2007 19:20:28 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 35149 invoked by uid 99); 12 Jul 2007 19:20:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2007 12:20:28 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2007 12:20:25 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D2984714212 for ; Thu, 12 Jul 2007 12:20:04 -0700 (PDT) Message-ID: <6169175.1184268004858.JavaMail.jira@brutus> Date: Thu, 12 Jul 2007 12:20:04 -0700 (PDT) From: "Mike Matrigali (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-2212) Add "Unique where not null" to create index In-Reply-To: <20254731.1167917367874.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-2212: ---------------------------------- What is the standard with respect to multi-column keys and the null uniqueness semantics for this feature. The Oracle semantics definitely seem easier to implement/understand. If this is not the standard what should happen in the following 3 part multi-column unique key but allow null duplicate instances: clearly not allowed: null, null, null vs null, null, null clearly not allowed: a, a, a vs a a a Is following a duplicate or not? a, null, b vs a, null, b a, null, null vs a, null, null null, a, b vs null a, b The Derby store is architected to allow the SQL engine to create an index which would only have a subset of rows of the base table. This would be easy. The challenge would be to enhance the existing engine code to understand how it could use this index. So for instance would be wrong to use this new index for optimized isNull() lookup, also won't work for count *, and the consistency checker probably would need to change as it assumes matching number of rows between base table and indexes. Depending on the answer above optimizer may even more limited on what it could use the index for. There are probably other things. Long term I believe there are other uses for these kinds of non-standard indexes so I think work in this area may help other projects, like functional indexes. > Add "Unique where not null" to create index > ------------------------------------------- > > Key: DERBY-2212 > URL: https://issues.apache.org/jira/browse/DERBY-2212 > Project: Derby > Issue Type: Improvement > Components: SQL > Affects Versions: 10.2.1.6 > Reporter: Oleksandr Alesinskyy > > Derby prohibits creation of unique constraints on nullable colums (as well if only some columns in the constraint list are nullable) and treat nulls in unique indexes as normal values (i.e. only one row with null values in indexed columns may be inserted into the table). This bahavior is very restrictive, does not completely comply with SQL standards (both letter and intent) as well as with business needs and intending meaning of NULL values (2 null values are not considered as equal, this comparision shall return NULL, and for selection criteria boolean null is treated as FALSE). > This behavior, as far as I can see, is modelled after DB2 (and differs from behavior of most other major databases, like SyBase, Oracle, etc.). > But even DB2 provide some means to alleviate these restrictions, namely "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement. > It will be very good if such "UNIQUE WHERE NOT NULL" clause will be introduced in Derby. > Regards, > Oleksandr Alesinskyy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.