Usa ID (numerico) sui nomi come chiave univoca?

1

Ho un set di dati (supponiamo che siano oggetti) con nomi unici immutabili , come questo:

class Datum {
    final string name
    // other fields
}

Considerando che:

  1. Non ho bisogno di supportare rinomina . (I nomi sono immutabili come ho detto)
  2. I nomi sono unici . Tra i dati che immagazzino, non ci sono due dati con lo stesso nome.
  3. Potrebbero esserci o no (a seconda di come i futuri plugin utilizzeranno l'API) essere un sacco di chiamate API per cercare un riferimento per nome .

Dovrebbe Quando dovrei indicizzare i miei dati con un ID numerico di addizione, o piuttosto che solo con il nome?

  • nei database?
    • L'ID sarebbe una chiave primaria auto_increment dal motore di database
    • Il nome è fornito
  • in una memoria di runtime (probabilmente hashtable, ma anche altre strutture dati che potrebbero essere applicabili)?
    • L'ID è un valore di incremento associato a ciascun dato quando viene caricato un riferimento.
    • I dati possono essere inseriti o rimossi dallo storage in qualsiasi momento senza un ordine specifico e possono essere reinseriti (dopo essere stati rimossi), ma lo stesso dato si verifica solo nella memoria una volta allo stesso tempo.
    • Prendi in considerazione l'implementazione in diverse lingue. Ad esempio, in Java, è possibile utilizzare un HashMap<String, ?> rispetto a HashMap<Integer, ?> . In PHP, la differenza è la chiave utilizzata nella matrice che memorizza i dati.

Note: The two questions are independent from each other, i.e. yes for database only but no for runtime only may also be a reasonable answer.

    
posta SOFe 10.10.2016 - 15:11
fonte

2 risposte

2

Il caso che descrivi è così bizzarro che mi chiedo se sia puramente teorico.

Ecco i fatti come li ho capiti:

  1. Devi avere un nome univoco indipendente dalla necessità di univoco Identifier
  2. Le persone cercheranno i dati con quel nome e i nomi sarà inserito dall'utente (non generato automaticamente)
  3. Non ti interessa quale sia il nome, cioè se viene inserito un errore non è necessario correggerlo.

Il vantaggio principale dell'utilizzo di una chiave generata automaticamente è la facile creazione di nuovi record. (Auto incrementato o un ID testo creato automaticamente è lo stesso), non è necessario verificare se un valore esiste già prima di inserirlo, non è necessario chiedere all'utente di inserirlo.

Ora, se si deve controllare se esiste già un valore prima di inserirlo e si chiede all'utente uno. Non c'è bisogno di un'altra chiave, puoi semplicemente usare Nome. Ma io strongmente ti esorto a verificare le tue ipotesi.

    
risposta data 10.10.2016 - 16:07
fonte
0

Questo ha senso per me. Ci sono alcuni problemi in cui il modello di business offre una "chiave primaria" naturale.

Se puoi garantire che il tuo campo unico è in effetti unico e immutabile, allora puoi anche usarlo.

In altre parole, aggiungere una chiave generata può migliorare la tua app?

Detto questo, sono d'accordo con Morons - è molto raro imbattersi in una situazione in cui è possibile quella sorta di garanzia ferrea.

Un possibile esempio potrebbe essere se si dovessero memorizzare informazioni relative a una scacchiera - ci sono 64 quadrati, con le righe numerate da 1 a 8 e le colonne etichettate a - g. Non ci sarà mai più, e "a1" è garantito per essere unico.

Negli affari, si è tentati di utilizzare "codice prodotto" o "codice articolo" come ID. Non farlo.

    
risposta data 10.10.2016 - 16:16
fonte

Leggi altre domande sui tag