Ai-je besoin d'ID dans ma base de données si les enregistrements peuvent être identifiés par la date?

J'écris ma première application pour Android et j'utiliserai la base de données SQLite, j'essaierai donc de limiter la taille autant que possible, mais je pense que la question s'applique en général à la conception de la base de données.

Je prévois de stocker des enregistrements contenant du texte et la date de création. L'application est une application autonome, c'est-à-dire qu'elle ne sera pas liée à Internet et qu'un seul utilisateur la mettra à jour, il n'y a donc aucune chance qu'il y ait plus d'une entrée avec une date donnée.

Ma table a-t-elle encore besoin d'une colonne ID? Dans l'affirmative, quels sont les avantages d'utiliser l'ID comme identifiant d'enregistrement par rapport à la date?

À mon humble avis, il vaut mieux éviter d'utiliser une colonne de date comme clé primaire.

J'ai travaillé sur des systèmes où un champ de date est utilisé comme clé primaire et l'écriture de requêtes pour retirer des sous-ensembles de données est un peu compliquée si vous travaillez avec des champs de date.

Quelques autres points que vous voudrez peut-être considérer:

Vous pourriez penser qu'un point dans le temps est unique, mais cela dépend plutôt de la granularité de la colonne de date. S'agit-il de minutes, secondes, millisecondes, etc. Pouvez-vous être absolument sûr que vous n'obtiendrez jamais de violation de clé primaire?

Enfin, si vous souhaitez migrer la base de données vers une autre plateforme, vous pouvez à nouveau rencontrer des problèmes où la granularité des données de date diffère entre les plateformes.

Vous devez bien sûr trouver un équilibre entre l'idéal et ce avec quoi vous devez travailler. Si l'espace est vraiment un sujet de préoccupation, l'utilisation de la colonne date pourrait être le moindre de deux maux. C'est une décision de conception que vous devrez prendre.

Éditer:

Je dois souligner que cela n'indique nullement qu'il s'agit d'une mauvaise décision de conception. Juste qu'il pourrait y avoir des problèmes avec les aspects pratiques du SGBDR en question.

Non, vous n'avez pas strictement besoin d'une colonne ID définie dans votre schéma si vous pouvez garantir qu'il n'y aura jamais de date en double.

MAIS ...

... cela dit, vous pourriez aussi bien l'utiliser de toute façon. Le petit secret ici est que SQLite a déjà un ID unique à incrémentation automatique pour chaque table appelée ROWID. Si vous déclarez une colonne entière à incrémentation automatique dans votre table en tant que PK, SQLite ne créera pas de nouvelle colonne - elle aliasera simplement cette colonne ROWID préexistante.

Dans SQLite, chaque ligne de chaque table a un ROWID entier signé 64 bits. Le ROWID de chaque ligne est unique parmi toutes les lignes de la même table.

Vous pouvez accéder au ROWID d'une table SQLite en utilisant l'un des noms de colonne spéciaux ROWID, ROWID ou OID. Sauf si vous déclarez une colonne de table ordinaire pour utiliser l'un de ces noms spéciaux, l'utilisation de ce nom fera référence à la colonne déclarée et non au ROWID interne.

Si une table contient une colonne de type INTEGER PRIMARY KEY, cette colonne devient un alias pour le ROWID. Vous pouvez ensuite accéder au ROWID en utilisant l'un des quatre noms différents, les trois noms d'origine décrits ci-dessus ou le nom donné à la colonne INTEGER PRIMARY KEY. Tous ces noms sont des alias les uns pour les autres et fonctionnent aussi bien dans n'importe quel contexte.

http://www.sqlite.org/autoinc.html

Donc, vous n'économiserez pas d'espace en n'utilisant pas de colonne ID car vous en obtenez une par table, que vous le vouliez ou non!

Utilisez un champ ID si l'une des conditions suivantes est vraie:

1. Aucune clé naturelle n'existe (la date ne sera pas unique)
2. Le champ de date changera souvent
3. La date peut ne pas être connue au moment de l'insertion.
4. Un identifiant multicolonne dépasse trois colonnes, ce qui rendrait les jointures trop verbeuses.

Lisez cette question: Existe - t-il une source canonique prenant en charge les «substituts de substitution»?

Éditer:

Puisque, à mon avis, il semble que rien de ce qui précède ne soit vrai, vous n'avez pas besoin d'utiliser le champ ID, mais vous pouvez en utiliser un si vous le souhaitez.

Gardez à l' esprit que vous pouvez également changer le sens de la colonne « date » de created_atla updated_atou tout autre changement dans ce sens, que je trouve être le cas très fréquent.

L'ajout d'une colonne d'identification dans certains cas vous donnera plus de flexibilité lorsque votre conception change.