100+ tables JOIN

Question

Je me demandais si quelqu'un avait déjà eu un changement pour mesurer la performance d'une centaine de tables jointes? Chaque table aurait une colonne d'ID avec l'index principal et toutes les tables sont liées 1: 1.

Il s'agit d'un problème courant dans de nombreuses applications de saisie de données où nous devons collecter plus de 1000 points de données. Une solution serait d'avoir une grande table avec plus de 1000 colonnes et l'alternative serait de les diviser en plusieurs tables et de les joindre quand cela est nécessaire.

question donc peut-être plus réel serait de savoir comment les 30 tables (30 colonnes chacun) se comporteraient avec multitable rejoindre.

500K-1M lignes doit être la taille attendue des tables.

Vive

Answer 1

En règle générale, plus que 25 pourrait être un joint problème de performance. J'essaie de garder les jointures en dessous de 10-15. Cela dépend de l'activité de la base de données et du nombre d'utilisateurs simultanés, ainsi que du taux de lectures/écritures.

Suggestion de voir les vues indexées.

Avec une base de données bien paramétrée, les «bons» index pour la charge de travail de requête sont la clé.

Answer 2

Ils avaient très probablement effectuer terriblement, à moins que vous avez eu un très petit nombre de lignes par table.

Optez pour une table plus large, mais normalisez-la correctement. Ma conjecture est que si vous normalisez vos données correctement, vous aurez un design légèrement plus sain.

Answer 3

Il n'y a aucun moyen de mieux organiser les tables? Par exemple une table "DataPointTypes" et "DataPointValues"? Par exemple (et je ne connais pas vos circonstances particulières) si toutes vos tables sont comme "WebsiteDataPoints (WebsitePage, Day, Visits)" "StoreDataPoints (Branche, Semaine, Ventes)" etc. vous pourriez avoir

DataPointSources(Name) 
(with data: Website,Store) 

DataPointTypes(SourceId, ColumnName) 
(with data: (Website, WebsitePage), (Website, Day), (Store, Branch), (Store, Sales) etc.) 

DataPointEntry(Id, Timestamp) 

DataPointValues (EntryId, Value(as varchar probably)) 
(with data: (1, Website-WebsitePage, 'pages.php'), (2, Store-Branch, 'MainStore'), (1, Website-Day, '12/03/1980'), (2, Store-Sales '35') etc.) 

de cette façon, chaque table devient une source, chaque colonne devient un type, chaque ligne devient une entrée, et chaque cellule devient une valeur.

Answer 4

Ce que vous décrivez est similaire à l'implémentation de column-oriented database (wikipedia). Les données sont stockées au format "column major", ce qui ralentit l'ajout de chaque ligne, mais est beaucoup plus rapide pour l'interrogation dans le cas d'une clause where qui restreint l'ensemble de lignes retourné.

Pourquoi est-ce que vous préférez diviser les lignes? Est-ce que vous mesurez les éléments de données pour chaque rangée à différents moments? Ou est-ce que le résultat d'une requête serait très grand?

Depuis la première publication, vous me répondit-dessous que votre raison de vouloir une scission de la table est que vous travaillez habituellement seulement un sous-ensemble des données.

Dans ce cas, le fractionnement de la table peut aider votre performance (quantité d'exécution consommée par la requête) une certaine quantité. Cela peut être un facteur important dans votre volonté de travailler avec moins de données - dans le cas où votre moteur de base de données s'exécute lentement avec de grandes lignes.

Si les performances ne sont pas un problème, plutôt que d'utiliser SQL JOIN, il peut vous servir à la liste explicitement les colonnes que vous souhaitez récupérer dans chaque requête.Par exemple, si vous souhaitez uniquement récupérer la largeur, la hauteur et la longueur d'une ligne, vous pouvez utiliser: SELECT width, height, length FROM datatable; plutôt que SELECT * FROM datatable; et d'obtenir la même amélioration pour obtenir moins de données renvoyées. Les instructions SQL utilisées seraient probablement plus courtes que les autres instructions de jointure envisagées.