94 lines
3.2 KiB
Markdown
94 lines
3.2 KiB
Markdown
## Concevoir et manipuler la base de données SQLite de manière optimale
|
|
|
|
### Identifiants
|
|
|
|
| V1 |
|
|
|:--:|
|
|
| 24 |
|
|
|
|
### Catégories
|
|
|
|
| Cycle de vie | Tiers | Responsable |
|
|
|:---------:|:--------------------:|:----:|
|
|
| 3. Réalisation (fabrication / développement) | Terminal utilisateur | Architecte Logiciel/Développeur |
|
|
|
|
### Indications
|
|
|
|
| Degré de priorité | Mise en oeuvre | Impact écologique |
|
|
|:-------------------:|:-------------------------:|:---------------------:|
|
|
| 3 | 3 | 3 |
|
|
|
|
| Ressources Economisées |
|
|
|:-------------------------------------------------------:|
|
|
| Processeur / Mémoire vive |
|
|
|
|
### Description
|
|
|
|
Lors de la conception de la base de données SQLite locale, il existe plusieurs optimisations pouvant être faite permettant de réduire la consommation mémoire et les cycles processeurs nécessaires lors de l'exécution de certaines requêtes.
|
|
Par exemple :
|
|
* L'utilisation de `PRIMARY KEY` sur l'identifiant d'une donnée permet de bénéficier d'une recherche par identifiant optimisée (reposant sur l'utilisation en interne d'un [B-Tree](https://en.wikipedia.org/wiki/B-tree))
|
|
* Pour optimiser les requêtes sur un champ spécifique de type filtrage `WHERE`, tri `ORDER BY` ou regroupement `GROUP BY`, il peut être intéressant d'ajouter un index sur ce champ. Attention cependant a ne pas créer inutilement un index, car cette pratique a un coût en termes de stockage.
|
|
* Si la donnée à stocker est volumineuse, stocker plutôt cette donnée dans un fichier, et si besoin référencer le chemin vers ce fichier dans la base de donnée locale.
|
|
* Lors de la lecture, récupérer uniquement les données dont l'application a besoin.
|
|
* Utiliser au maximum les opérateurs de requêtes fournis par SQL comme les requêtes imbriquées ou les jointures plutôt que de faire ces manipulations dans le code. En effet, ces opérateurs sont optimisés.
|
|
* En cas d'insertion multiple de données, utiliser une transaction plutôt que d'effectuer unitairement chaque insertion.
|
|
|
|
### Exemple
|
|
|
|
* Soit une application permettant de gérer des contacts. Si notre application est susceptible de vouloir accéder à un contact précis à partir de son identifiant, écrire :
|
|
|
|
```sql
|
|
CREATE TABLE Contact(
|
|
id INTEGER PRIMARY KEY,
|
|
name TEXT,
|
|
city TEXT
|
|
);
|
|
```
|
|
|
|
plutôt que :
|
|
|
|
```sql
|
|
CREATE TABLE Contact(
|
|
id INTEGER,
|
|
name TEXT,
|
|
city TEXT
|
|
);
|
|
```
|
|
|
|
* Sur cette même application de gestion de contacts, les requêtes de ce style sont fréquemment exécutées :
|
|
|
|
```sql
|
|
SELECT id, name
|
|
WHERE city = 'Lille, France';
|
|
```
|
|
|
|
Pour optimiser ce genre d'opération, créer un index comme ceci :
|
|
|
|
```sql
|
|
CREATE INDEX city_index ON Contact(city);
|
|
```
|
|
|
|
* Récupérer les données dont nous avons besoin :
|
|
|
|
```sql
|
|
SELECT name
|
|
FROM Customers
|
|
LIMIT 10;
|
|
```
|
|
|
|
plutôt que :
|
|
|
|
```sql
|
|
SELECT *
|
|
FROM Customers;
|
|
```
|
|
|
|
|
|
Source : [SQLite performance best practices](https://developer.android.com/topic/performance/sqlite-performance-best-practices)
|
|
|
|
### Principe de validation
|
|
|
|
| Le nombre ... | est inférieur ou égal à |
|
|
|-------------------|:-------------------------:|
|
|
| de requêtes SQL à l'intérieur d'une boucle | 0 |
|