Table d'utilisateurs multiples VS 1 tables d'utilisateurs?

Question

Je suis dans une situation de dilemme. Je ne suis pas sûr si c'est une bonne idée de séparer la table des utilisateurs. Je remarque les performances de ma table de jeu, alors que les nombres augmentent, le chargement devient de plus en plus lent.

Ma table d'utilisateurs actuelle stocke tous les utilisateurs, qui actuellement environ 10k utilisateurs. Je pense à diviser le Tableau des utilisateurs (pour l'avenir) dans ce genre:

Connexion Tableau => Connexion utilisateur du magasin de détails

========================================== 
= id | username | password | tableid = 
========================================== 
= 1 | user1 | user1xx | 1  = 
= 2 | user2 | user2xx | 1  = 
... 
= 20k1 | user20k1 | user20k1 | 2  = 
etc 

utilisateurs des données

========================================== 
= id | money | items | preferences = 
========================================== 
= 1 | xx | xx | xx  = 
= 2 | xx | xx | xx  = 
... 
= 20k1 | xx | xx | xx  = 
etc 

Alors, lorsque je tente de obtenir les données des utilisateurs Je viens de quitter la requête pour obtenir les données.

Ma question est, existe-t-il des différences (vitesse, performances, etc.) entre le stockage des données des utilisateurs dans plusieurs tables et le stockage des données des utilisateurs dans un seul tableau? (En supposant que les index et clé primaire sont les mêmes)

Mes tableaux actuels index:

Jeux highscores table => colonnes: id, gameid, nom, score, date

Clé primaire: id

Index: gameid

Connexion Tableau => Colonnes: id, nom d'utilisateur, mot de passe

clé primaire: id (ID utilisateur)

Index: Nom d'utilisateur

utilisateurs de données => Colonnes: alots

Index: id

Answer 1

Il semble que la vraie question que vous avez ici est la suivante: pourquoi ma application est lente. Tout d'abord, la division des données entre plusieurs tables ne va pas améliorer les performances. Si c'est bien fait (pour des raisons autres que la performance), cela ne nuira pas à la performance, mais je doute que cela puisse aider.

De plus, selon mon expérience, c'est une mauvaise idée d'optimiser en fonction de la sensation intestinale. Les suppositions sur ce qui retient votre programme sont généralement fausses. Vous finissez par faire beaucoup de réécriture sans aucun gain de vitesse.

La première étape pour l'accélérer est de trouver le véritable goulot d'étranglement. Vous devez ajouter de l'instrumentation et collecter des statistiques pour déterminer s'il s'agit d'une base de données ou d'un serveur d'applications. Est-ce un sproc particulier ou pourrait être la bande passante de votre réseau. Ou peut-être qu'il y a du javascript sur vos pages.

Une fois que vous savez quoi corriger, vous pouvez essayer de le réparer.

Answer 2

Si vous interrogez pour les bits d'information et vous avez beaucoup de (edit:) colonnes, il est En fait, c'est vraiment une bonne idée de les séparer et vous n'avez pas besoin du champ tableid dans la table des utilisateurs, il vous suffit d'une clé étrangère dans la table d'informations qui pointe vers l'utilisateur associé dans la table users.

Vous pouvez avoir plusieurs tables comme celle-ci et les joindre comme vous le souhaitez, les performances vont probablement augmenter.

Answer 3

On dirait que diviser la table ne vous fera pas du bien. Il semble qu'une corrélation 1: 1 se produirait entre les tables, et cela ajouterait simplement une deuxième requête chaque fois que vous voudriez quelque chose de cette table. Essayez d'utiliser Partitioning sur la table pour aider avec les performances dans cet aspect. La normalisation n'est utile que si vous avez des données redondantes (vous avez donc le même utilisateur dans votre table utilisateur 5 fois). Utile si vous souhaitez réduire l'utilisation des données avec des scores élevés pour plusieurs jeux, mais en fin de compte cela ne vous donnera probablement pas une augmentation des performances sur la table.