Cosa sta impedendo a Oracle di supportare colonne di identità (auto-numeriche)? [chiuso]

Le priorità di Oracle sono molto diverse da quelle degli sviluppatori di tutti i giorni.

Dalla mia esperienza classificherei l'atteggiamento di Oracles come segue:

Priorità alta

• Reliablity: se una cosa ti fa apparire male nel mondo RDBMS, viene distrutto dati, backup danneggiati e istruzioni selezionate che restituiscono dati errati.

• Prestazioni: i clienti che pagano davvero un sacco di soldi (e a chi importa il resto?) hanno enormi database e molto lavoro da fare. Quindi le cose che rendono veloci i grandi database sono caratteristiche che si vendono da sole

Bassa o nessuna priorità

• Usabilità dello sviluppatore: se uno sviluppatore vuole lavorare su qualcosa di carino e di fantasia, ha lasciato RDBMSes molto tempo fa. Quindi il resto non si preoccupa di saltare attraverso i cerchi per qualche compito di base. Hanno anche acquisito così tanto know how specializzato Oracle, che i sistemi di commutazione sono difficili.

Ci sono un sacco di cose che rientrano in questa categoria: integrazione degli strumenti con i sistemi Version Control; gestione per migrazioni di database; Tipo di dati booleano per colonne di tabelle; Colonne identità.

Per tutte queste cose e probabilmente molte altre ci sono alcuni workaround / patch che in qualche modo portano a termine il lavoro. Come nel caso delle sequenze ancora più potenti e flessibili, ma scomode. Ma poiché quasi nessun cliente pagante sceglie il RDBMS in base alla sua gentilezza per lo sviluppatore, a Oracle non importa.

Per avere un'idea della mentalità di Oracle (e di molti sviluppatori / amministratori che lavorano con o per Oracle) lasciatemi citare un pezzo di Tom Kyte :

You Asked

Here's a real short one for you Tom:

Why doesn't Oracle RDBMS have a boolean datatype?

and we said...

since

...,
flag char(1) check (flag in ( 'Y', 'N' )),
...,

serves the same purpose, requires the same amount of space and does the same thing - I guess we feel this is a feature we can let them have that we really don't need.

I mean - what do you get back from a column in "access" that is a boolean? TRUE / FALSE. We'll give you Y/N -- if you would like TRUE/FALSE, we can accomplish that easily with DECODE(flag,'Y','TRUE','N','FALSE')

Che personalmente traduco in: Chi ha bisogno di tipi? Assembler va bene.

link

Il database 12c introduce la possibilità di definire una clausola di identità su una colonna della tabella definita utilizzando un tipo numerico. La sintassi è mostrata di seguito.

GENERATED
[ ALWAYS | BY DEFAULT [ ON NULL ] ]
AS IDENTITY [ ( identity_options ) ]

Sto solo indovinando qui, ma probabilmente per ragioni ereditarie.

Sequenze e amp; le colonne di identità hanno proprietà fastidiose come il mancato rispetto delle transazioni. Le sequenze forniscono in realtà una maggiore flessibilità rispetto a una colonna di identità semplice in quanto consentono a te, lo sviluppatore, di decidere come e quando applicare la sequenza.

Le sequenze ti danno anche la possibilità di conoscere il numero di sequenza assegnato prima di dover inserire il record.

Nota a margine, se in futuro prevedi di supportare la replica o qualsiasi forma di disconnessione (ad es. dispositivi mobili o connessioni offline al tuo database) ti suggerirei di utilizzare i GUID come chiave. In questo modo rimuovi i problemi relativi al partizionamento delle sequenze, ecc.

Non conosco la sequenza in Oracle db ma cerco di evitare di utilizzare colonne identity. Solitamente le colonne Identity vengono utilizzate come chiavi sostitutive e sembrano funzionare bene all'inizio, ma prima o poi quando l'azienda richiede di trasferire / esportare / importare dati tra sistemi e client, le colonne Identity sono le più problematiche da gestire.