Matrix : What you must learn is that these rules are no different than rules of a computer system. Some of them can be bent, others can be broken. Understand?
Usually an unique index grants the uniqueness of all rows in a specific table which have non-null values; But what if some data depended on a given business type in the the row of table needs to be unique and some not? combining function based index feature from Oracle with a unique index makes this possible.
-- SCOPE : OASIS
-- DDL:CALLITEMS_UK01 :INDEX.MOD - TEST
DROP INDEX CALLITEMS_UK01;
CREATE UNIQUE INDEX CALLITEMS_UK01
( CASE UNIQUE_REF WHEN 1 THEN UPPER(TRIM(ITEMCODE)) ELSE NULL END
, CASE UNIQUE_REF WHEN 1 THEN ITEMTYPE ELSE NULL END
, CASE UNIQUE_REF WHEN 1 THEN ACTIVESINCE ELSE NULL END )
Dependend on the uniqeness flag UNIQUE_REF a row may be unique to others or not. Maybe this makes sense for specific call item types. In our project a CALLITEMTYPES table controlled the unqueness of specifc call item types , pupulating the UNIQUE_REF flag to the CATLLITEMS table.
Since I joined a Big Data Event : Frankfurter Datenbanktage 2013 - I started to take also a look to non-relational technics too. The RDBMS is not for every asepct the correct and fitting and fulfilling answer to all data related IT challenges.
Frequently I wondered about how facebook could handle such an dramatic amount of users and data growth. I found an interesting presentation from the facebooks HDFS - Development-Lead Hairong Kuang optimizing HDFS (Hadoop DFS) for Scalability, Storage Effiency and Availability.
An RDBMS would not scale to that amount of load - reasons for that is the explained in theory with the CAP-Theorem which I will post about later;
Now to the presentation on InfoQ : http://www.infoq.com/presentations/Hadoop-HDFS-Facebook