_id est utile lorsque vous utilisez les adaptateurs améliorés qui utilisent un curseur (par exemple ResourceCursorAdapter). Il est utilisé par ces adaptateurs pour fournir un ID qui peut être utilisé pour faire référence à la ligne spécifique du tableau qui relie l'élément dans quoi que ce soit pour lequel l'adaptateur est utilisé (par exemple une ligne dans un ListView).
Ce n'est pas nécessaire si vous n'utilisez pas de classes qui nécessitent une colonne _id dans un curseur, et vous pouvez également utiliser "as _id" pour faire apparaître une autre colonne comme si elle s'appelait _id dans votre curseur.
Pourquoi ne pas utiliser _ ROWID _ ?
SQLite fournit cela de toute façon pour chaque ligne, vous pouvez donc simplement l'aliaser à _id dans votre instruction select.
Techniquement pas le domaine _id n'est pas requis, cependant si vous utilisez la classe CursorAdapter (ce que vous êtes probablement, surtout si vous travaillez avec l'exemple du Bloc-notes) alors oui
"Le curseur doit inclure une colonne nommée" _id "sinon cette classe ne fonctionnera pas"
comme expliqué dans la documentation ici . Malheureusement, les exemples de code ne rendent pas cela très clair.
Il est très pratique dans de nombreux cas d'avoir un champ id. Je préfère que le mien soit auto-incrémenté (comme indiqué ci-dessous). Je trouve toujours de nouvelles utilisations pour le champ id :)
Quand vient le temps d'attacher les données à un adaptateur, j'aime utiliser un alias de nom de table pour interroger le champ id comme _id. Exemple: SELECT id _id, msg from message order by id. De cette façon, l'adaptateur voit un champ appelé _id et tout le monde est content.
Voici un exemple de la façon dont je définis mes tables:
CREATE TABLE message (_id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp INTEGER, tripID TEXT, msg TEXT);
Si vous définissez votre colonne _id comme un entier à incrémentation automatique, il s'agit en fait d'un alias pour la colonne ROWID que SQLite fournit par défaut ( https://www.sqlite.org/lang_createtable.html#rowid ).
Votre instruction create doit prendre la forme ...
CREATE TABLE t(_id INTEGER PRIMARY KEY ASC, y, z);
Pour prouver que cela fonctionne ...
UPDATE t SET _id=22 WHERE _id=11;
puis
SELECT ROWID, _id FROM t;
et vous trouverez les deux _id et ROWID ont la même valeur.
Notez que si vous utilisez DESC dans CREATE, une nouvelle colonne est créée et ROWID n'est pas aliasée.
De la documents officiels ...
Le curseur doit inclure une colonne nommée "_id" sinon cette classe ne fonctionnera pas. En outre, l'utilisation de MergeCursor avec cette classe ne fonctionnera pas si les curseurs fusionnés ont des valeurs qui se chevauchent dans leurs colonnes "_id".
Et le Cursor est:
Cette interface fournit un accès aléatoire en lecture-écriture au jeu de résultats renvoyé par une requête de base de données.
En d'autres termes, vous avez besoin de _id pour Android SQLite (qui utilise généralement le curseur)
Sûrement pas. C'est un champ pratique que certains widgets comme ListView utilisent pour remplir les données. Voir ce bon article: http://www.casarini.org/blog/2009/Android-contentprovider-on-sqlite-tables-without-the-_id-column/
Bien sûr, si vous créez votre propre widget d'interface utilisateur et votre propre adaptateur, vous n'avez pas besoin de nommer votre clé primaire en tant que "_id". Il peut s'agir de n'importe quel nom que vous souhaitez. Mais vous seriez responsable de la gestion de vos collections de widgets d'interface utilisateur et de leur liaison à la bonne ligne de votre base de données. "_id" n'est utile que pour ListView comme Brad l'a souligné.