Lorsqu'une colonne entière est marquée comme clé primaire dans une table SQLite, un index doit-il être explicitement créé pour elle aussi ? SQLite ne semble pas créer automatiquement un index pour une colonne à clé primaire, mais peut-être l'indexe-t-il quand même, étant donné son objectif ? (Je ferai des recherches sur cette colonne en permanence).
La situation serait-elle différente pour une clé primaire de type chaîne ?
À part les colonnes INTEGER PRIMARY KEY, les deux colonnes UNIQUE et PRIMARY KEY sont implémentées en créant un index dans la base de données (de la même base de données (de la même manière qu'une instruction "CREATE UNIQUE INDEX"). Un tel est utilisé comme n'importe quel autre index de la base de données pour optimiser les requêtes. Par conséquent, il n'y a souvent pas d'avantage (mais une surcharge importante) à créer un index sur la base de données. de créer un index sur un ensemble de colonnes qui sont déjà soumises à un index soumises collectivement à une contrainte UNIQUE ou PRIMARY KEY.
En effet, il est dit "L'attribut PRIMARY KEY crée normalement un index UNIQUE sur la ou les colonnes qui sont spécifiées comme PRIMARY KEY". Cependant, cet index n'est pas visible dans les applications de gestion SQLite, c'est pourquoi j'ai posé la question.
Ce qui signifie que, contrairement à mysql, vous devez souvent ajouter des index lorsque vous créez des clés étrangères. Est-ce le cas ?
Si une colonne est marquée INTEGER PRIMARY KEY, il s'agit en fait d'environ deux fois plus rapide qu'une recherche similaire effectuée en spécifiant toute autre valeur PRIMARY KEY ou indexée . C'est parce que :
...toutes les lignes des tables SQLite ont une clé entière signée de 64 bits qui identifie de manière unique la ligne dans sa table ... La recherche d'un enregistrement avec un rowid spécifique, ou de tous les enregistrements avec des rowids dans une plage spécifiée est environ deux fois plus rapide qu'une recherche similaire effectuée en spécifiant n'importe quelle autre clé PRIMAIRE ou valeur indexée.
À une exception près, notée ci-dessous, si une table rowid a une clé primaire qui consiste en une seule colonne et le type déclaré de cette colonne est "INTEGER". dans n'importe quel mélange de majuscules et de minuscules, alors la colonne devient un alias pour le rowid.
Une telle colonne est généralement appelée "clé primaire entière". A colonne PRIMARY KEY ne devient une clé primaire entière que si le nom du type déclaré est exactement "INTEGER". D'autres noms de types entiers comme "INT" ou "BIGINT" ou "SHORT INTEGER" ou "UNSIGNED INTEGER" font que la colonne de clé primaire se comporte comme une colonne ordinaire. primaire se comporte comme une colonne de table ordinaire avec une affinité entière et un index unique, et non comme un alias pour le rowid.
Une base de données créera toujours en silence un index pour une clé primaire unique afin de pouvoir vérifier efficacement en interne qu'elle est unique.
L'ayant créé, il l'utilisera en cas de besoin.
Bien entendu, il ne sera pas toujours groupé, et vous devez généralement le spécifier dans le schéma si vous souhaitez qu'il le soit.
Lorsque vous utilisez
CREATE TABLE data(a INTEGER PRIMARY KEY, b, ...)la traditionnelle colonne supplémentaire (cachée) rowid ne sera pas là : la chronique a lui-même sera l'identifiant de la ligne.
En effet, le doc États :
En SQLite, une colonne avec le type INTEGER PRIMARY KEY est un alias pour le ROWID (sauf dans les tables WITHOUT ROWID) qui est toujours un entier signé de 64 bits.
si une table [...] a une clé primaire qui consiste en une seule colonne et que le type déclaré de cette colonne est "INTEGER" [...], alors la colonne devient un alias pour le rowid .
Depuis a est l'identifiant de la ligne, aucun index n'est nécessaire, les requêtes sur la colonne a sera rapide grâce à la structure B-tree :
Les données [...] sont stockées sous la forme d'une structure B-Tree contenant une entrée pour chaque ligne de la table, la valeur rowid servant de clé.
Note : la partie [...] que je n'ai pas citée est relative aux précisions sur les différences entre les tableaux normaux et les tableaux avec la fonction WITHOUT ROWID clause, mais c'est totalement hors sujet ici.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
