Ho bisogno di ID nel mio database se i record potrebbero essere identificati dalla data?

IMHO, è meglio evitare l'uso di una colonna di date come chiave primaria.

Ho lavorato su sistemi in cui un campo data viene utilizzato come chiave primaria e le query di scrittura per richiamare sottoinsiemi dei dati sono un po 'trascinanti se si lavora con i campi data.

Altri punti che potresti prendere in considerazione:

Potresti pensare che un punto nel tempo sia unico, ma ciò dipende piuttosto dalla granularità della colonna della data. Sono minuti, secondi, millisecondi, ecc. Puoi essere assolutamente sicuro che non otterrai mai una violazione della chiave primaria?

Infine, se si desidera migrare il database su un'altra piattaforma, è possibile che si verifichino problemi in cui la granularità dei dati di data differisce tra le piattaforme.

Ovviamente devi bilanciare l'ideale con ciò con cui devi lavorare. Se lo spazio è davvero una preoccupazione, usare la colonna della data potrebbe essere il minore di due mali. Questa è una decisione sul design che dovrai prendere.

Modifica

Vorrei sottolineare che in nessun modo questo indica che è una decisione di design scarsa . Solo che potrebbero esserci problemi con gli aspetti pratici del RDBMS in questione.

No, non hai strettamente bisogno di una colonna ID definita nel tuo schema se puoi garantire che non ci sarà mai una data duplicata.

MA ...

... detto questo, potresti comunque usarlo comunque. Il piccolo segreto qui è che SQLite ha già un unico ID autoincrementante per ogni tabella chiamata ROWID. Se dichiari una colonna di numeri interi a incremento automatico nella tabella come PK, SQLite non creerà una nuova colonna, ma farà semplicemente l'alias della colonna ROWID preesistente.

In SQLite, every row of every table has an 64-bit signed integer ROWID. The ROWID for each row is unique among all rows in the same table.

You can access the ROWID of an SQLite table using one the special column names ROWID, ROWID, or OID. Except if you declare an ordinary table column to use one of those special names, then the use of that name will refer to the declared column not to the internal ROWID.

If a table contains a column of type INTEGER PRIMARY KEY, then that column becomes an alias for the ROWID. You can then access the ROWID using any of four different names, the original three names described above or the name given to the INTEGER PRIMARY KEY column. All these names are aliases for one another and work equally well in any context.

link

Quindi, non starai risparmiando spazio non usando una colonna ID dato che ne stai ricevendo una per tabella, che tu lo voglia o no!

Utilizza un campo ID se si verifica una delle seguenti condizioni:

1. Non esiste alcuna chiave naturale (la data non sarà univoca)
2. Il campo della data cambierà spesso
3. La data potrebbe non essere nota al momento dell'inserimento.
4. Un identificatore a più colonne supera le tre colonne, il che renderebbe i join troppo dettagliati.

Leggi questa domanda: Esiste una fonte canonica che supporta " all-surrogati”?

Modifica

Poiché, a mio parere, sembra che nessuno dei precedenti punti sia vero, non è necessario per utilizzare e il campo ID, ma puoi usarne uno se lo desideri.

Ricorda che potresti anche voler cambiare il significato della colonna "data" da created_at a updated_at o qualsiasi altra modifica lungo quelle linee, che trovo essere un caso molto comune.

L'aggiunta della colonna ID in alcuni casi ti darà maggiore flessibilità quando il tuo progetto cambia.