Tableaux aplatis ou colonnes CSV : quelle conception de base de données offre de meilleures performances de requête ?

Optimisation de la base de données : tableaux aplatis ou colonnes CSV

Lors de la conception d'une base de données, la décision entre stocker les données dans une seule colonne avec une virgule -une valeur séparée (CSV) ou l'utilisation d'un tableau aplati avec une ligne pour chaque entrée se pose toujours. Cet article examine les implications de ces approches en termes de performances, en se concentrant sur les requêtes qui impliquent un filtrage ou une recherche.

Considérons une table SQL avec des lignes du formulaire :

value, "a,b,c,d,e,f,g,h,i,j", value3, value4

où les requêtes recherchent des paires comme valeur, %b% en utilisant l'opérateur LIKE.

En revanche, un tableau aplati aurait chaque permutation comme une valeur distincte row :

value, a, value3, value4
...
value, j, value3, value4

permettant aux requêtes d'utiliser l'opérateur = sur la valeur,b.

Pour ce cas d'utilisation spécifique, avec environ 10 000 lignes et une moyenne de 8 entrées par élément "liste" , les implications en termes de performances sont significatives.

Les requêtes LIKE ne peuvent pas exploiter les index, ce qui entraîne des recherches plus lentes. De plus, le stockage des données dans une seule colonne CSV est un anti-modèle qui peut nuire aux performances de la base de données.

Diviser la colonne CSV en colonnes distinctes et normaliser la base de données améliorerait considérablement l'efficacité. Ce faisant, les index peuvent être utilisés et l'opérateur LIKE peut être remplacé par l'opérateur =, ce qui accélère les requêtes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!