Discussion :

[clavier12AZQSWX]

bonjour,

j'ai une table avec plus de 40 champs dont 24 ayant besoin d'un index.
Au moment de la création, j'ai une erreur francisée qui dit :

#1070 - Trop de parties specifiées dans la clef. Maximum de 16 parties

je suppose que c'est l'erreur anglaise : too many key parts specified max 16 parts allowed

est-ce que ce 16 est modifiable ?
Ma version de mysql est 5.7.42-log (sur un hébergement mutualisé)


Merci de votre conseil et lecture.

[Séb.]

Tu veux créer 1 index contenant plus de 16 colonnes.

A maximum of 16 columns is permitted for multicolumn indexes. Exceeding the limit returns an error.

ERROR 1070 (42000): Too many key parts specified; max 16 parts allowed

https://dev.mysql.com/doc/refman/5.7...db-limits.html

[clavier12AZQSWX]

bonjour,

j'ai fait une erreur de manipulation.

J'utilise phpmyadmin, je me suis rendu compte que cocher plusieurs colonnes et utiliser l'option "index" en bas de la liste des champs, ne permettait pas de créer un index pour chacune des colonnes mais un index de colonnes fusionnées

en gros, au lieu de générer ça quand on coche les colonne 1 2 et 3:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
ALTER TABLE `personnes` ADD INDEX(`creneau01`); 
ALTER TABLE `personnes` ADD INDEX(`creneau02`); 
ALTER TABLE `personnes` ADD INDEX(`creneau03`);

il générait ceci :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE `personnes` ADD INDEX( `creneau01`, `creneau02`,`creneau03` );

ce qui n'est pas du tout la même chose ! ça m'apprendra à être fénéant et utiliser les outils IHM plutôt que les lignes de commandes !
Je passe en résolu!

même si je viens de découvrir qu'il existe aussi une limite de 64 champs indéxés par table !!

#1069 - Trop de clefs sont définies. Maximum de 64 clefs alloué

Conclusion : on peut pas utiliser une seule table pour gérer une matrice 3d de 24 champs !!

[Séb.]

Conclusion : on peut pas utiliser une seule table pour gérer une matrice 3d de 24 champs !!

Cela dépend sûrement de ta modélisation

[SQLpro]

Conclusion : on peut pas utiliser une seule table pour gérer une matrice 3d de 24 champs !!

Une matrice 3 D c'est du spatial. Le problème de MySQmerde c'est qu'il ne ait pas gérer le spatial à 3 dimenion. Même avec 2 dim il donne déjà des résultats faux.

Dans une cartouche SIG tu peut créer des nuages de points à 3 dimensions : X, Y et Z.... Voir mon cours sur le spatial. Mais les seuls SGBDR qui avent faire ça c'est Oracle, MS SQL Server PG ne gère pas le Y...

Exemple MS SQL Server :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DECLARE @POINTS GEOMETRY = CAST('MULTIPOINT ((25 12 3), (35 11 6))' AS GEOMETRY)

A me lire : https://blog.developpez.com/sqlpro/p...on_geographiqu

A +

[Artemus24]

Salut à tous.

j'ai une table avec plus de 40 champs dont 24 ayant besoin d'un index.

Les habitudes ont la vie dure. Il ne s'agit pas de champs mais de colonnes.
Pourquoi autant d'index pour une table contenant 40 colonnes ?

[clavier12AZQSWX]

Salut à tous.


Les habitudes ont la vie dure. Il ne s'agit pas de champs mais de colonnes.
Pourquoi autant d'index pour une table contenant 40 colonnes ?

une table qui gère des "produits" à plus de 24 propriétés sélectionnables (donc 24 tables étrangères différentes liées).
Dans un vieux poste, avant la création du schéma, je m'étais demandé s'il fallait créer une table catégorie "fourtout" où des valeurs numériques serait mélangées à des valeurs AN, pour simplifier le modèle relationnel.
Contre mon envie personnelle, j'ai donc opté pour la solution de rester "sémantique" et pas aller dans la bidouille. Même si je me suis rapproché du "keep it simple", je reste convaincu que la solution foure-tout aurait été la meilleure...

Le cas d'étude est simple : comment formaliser un produit à 40 propriétés.
-1 : Une seule table maitre et 40 tables étrangères pour chacune des propriétés
- 2 : une table maitre et une table "typologie (id,lib,valeur,typologie) et une table-relation appartenance pour faire le lien.
Le fait de mélanger dans une seule table des données métrique,date,AN était déconseillée....

C'est la même question qu'à du se poser l'ingénieur date de site amazon : un table avec chaque type de propriété ou une seule table propriété où l'on mélangerait des données de vêtements avec des données alimentaires avec des données techniques...

[escartefigue]

Pour ce qui concerne les recherches, hors considérations d'index couvrant donc, un index n'est pertinent que s'il est discriminant.
Par exemple, créer un index sur le code sexe d'une table des personnes physiques ne présente aucun intérêt concernant les recherches puisque grosso-modo, chaque valeur représentera 50% de l'effectif de la table.

Donc, avant de créer un index pour chaque colonne (et non pas "champ") de la table, vérifiez combien de valeurs distinctes chaque colonne peut prendre et quels sont les besoins de recherche sur chaque colonne.

Il ne faut pas oublier que chaque index impose une mise à jour supplémentaire lors des UPDATE, INSERT et DELETE, puisqu'il faut maintenir non seulement la page DATA et la page de l'index PK, mais aussi tous les autres index.
Evidement, les servitudes (réorgs, sauvegardes...) sont également pénalisées par la pléthore d'index, ainsi que l'espace disque.