Est-ce une bonne idée de créer une nouvelle table pour chaque client d'une webapp?

10

C'est semi-hypothétique, et comme je n'ai aucune expérience dans le traitement de tables de base de données massives, je n'ai aucune idée si c'est horrible pour une raison quelconque. Passons à la situation:

Imaginez une application Web - disons un logiciel de comptabilité - qui a 20 000 clients et chaque client a plus de 1000 entrées dans un tableau. C'est 20 millions de lignes qui, je le sais, peuvent certainement ralentir les requêtes complexes.

Dans un cas comme celui-ci, est-il plus logique de créer une nouvelle table dans la base de données pour chaque client? Comment les bases de données réagissent-elles à la présence de 20 000 tables (ou plus!)?

web-applications database-development

— Volonté
source

15

De manière générale, non, cela n'a aucun sens d'avoir une table (je pense que vous voulez dire une base de données ici) par client. 20 millions de lignes est relativement petit pour une table de base de données. La vitesse de requête par rapport à cela ne devrait pas être un problème tant que la base de données est correctement réglée (indexée) et que les requêtes sont correctement assemblées. Tout avantage que vous pensez retirer de leur séparation serait compensé par la complexité supplémentaire de la gestion de 20 000 bases de données individuelles. Par exemple, que se passe-t-il lorsque vous souhaitez modifier la structure de la table? Vous devez maintenant le faire 20 000 fois!

Pire encore, si vous constatez finalement que la taille de la base de données devient un problème, vous pouvez toujours les répartir dans des bases de données distinctes par la suite.

— GrandmasterB
source

non, je voulais dire littéralement des tables dans la base de données. Je ne peux pas imaginer une raison de créer une base de données par client. Et si 20 millions de lignes sont petites, quelles sont les grandes? Et que faites-vous à ce stade?

— Le

1

@ChrisF, exactement - il y a beaucoup de cas où la technologie ou le modèle commercial nécessite des bases de données distinctes par client. Mais je ne peux pas penser à une raison pour des tables séparées dans la même base de données.

— GrandmasterB

1

@GrandmasterB - Je pense que @Will pose la mauvaise question.

— ChrisF

1

@Will: Si possible, allez à une réunion Oracle User Group, ou l'équivalent pour une autre base de données haut de gamme. Vous constaterez que vos idées de «petit» et «grand» nécessitent beaucoup de réajustement. Cela m'est arrivé. Conseil: s'il tient sur un seul disque, il n'est pas volumineux selon les normes DBA.

— David Thornley

1

@Gorton, InnoDB est généralement considéré comme meilleur pour la fiabilité et la concordance, MyISAM pour la vitesse. Vous devez donc vraiment évaluer les différents moteurs de stockage en fonction de l'utilisation attendue de la base de données de votre application spécifique.

— GrandmasterB

5

Cela ressemble à une mauvaise idée.

N'essayez pas de déjouer la base de données avec des constructions exotiques comme celle-ci. Les moteurs de base de données sont conçus avec de nombreuses optimisations pour gérer de grands ensembles de données. Par exemple, ce que vous décrivez ressemble énormément à une tentative d'implémentation manuelle des index. Utilisez simplement les index fournis par le moteur de base de données, ils sont implémentés bien mieux que vous ne pourrez probablement le faire vous-même, et cela ne nécessitera pas autant de maintenance.

Aussi, en règle générale. Je suggère de ne pas architecturer une base de données d'une manière qui nécessite la manipulation ou la création de structures de base de données (tables, champs) lors de l'utilisation normale de l'application. Cela rend l'optimisation des performances un ours et vous oblige souvent à donner trop d'autorisations aux utilisateurs pour effectuer des tâches de routine susceptibles de créer des failles de sécurité.

— JohnFx
source

Je voterais une fois pour chacun de vos deux paragraphes si cela était autorisé.

— David Thornley

3

Voici un article que j'invite toujours les gens à lire lorsqu'ils posent cette question:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

— Mchl
source

Je n'avais aucune idée qu'une base de données crée un fichier réel par table = x

— sera

1

Cela peut dépendre du SGBDR réel utilisé. MySQL fait cela (jusqu'à trois fichiers par table si vous utilisez MyISAM). D'autres non.

— Mchl

La version d'entreprise de SQL Server le fera si vous le concevez de cette façon, mais pas automatiquement.

— JeffO

Oracle ne fait certainement pas cela.

— user281377

Oracle peut le faire, de la même façon que SQL Server peut le faire, mais je ne peux pas imaginer pourquoi vous jamais concevoir votre schéma d'avoir un fichier par table. Il est logique de fractionner une base de données en plusieurs fichiers, mais pas un fichier par table.

— Dean Harding

1

À mon humble avis, une seule table ne devrait pas être un problème, alors ne créez pas de problème là où il n'en existe pas - pour le moment. Vous pouvez faire beaucoup pour améliorer les performances. Vous pouvez partitionner une seule table en plusieurs fichiers en fonction de clientID ou d'un champ de date pour aider avec IO. Votre base de données n'a pas à suivre, optimiser et mettre en cache 20 000 instructions SQL différentes pour chaque requête dont vous aurez besoin. Vous pouvez indexer par clientid. Les clients 20K peuvent payer pour beaucoup de matériel.

Pour ce type de table, une base de données de type NoSQL peut être utilisée.

Avec 20 000 clients, la base de données n'est peut-être pas votre maillon le plus faible, alors pourquoi introduire autant de complexité?

— JeffO
source

`Vous pouvez partitionner une seule table en plusieurs fichiers en fonction de clientID ou d'un champ de date pour aider avec les entrées-sorties. '- Je ne sais pas ce que vous entendez par là. Une clarification?

— Le

Plusieurs fichiers sur le système d'exploitation. Un serveur peut faire plus de lecture / écriture sur de nombreux fichiers au lieu d'un seul.

— JeffO

Je suppose que je voulais dire: je n'ai jamais entendu parler d'une telle chose, où puis-je trouver plus d'informations sur le faire? :-) Mais je vais toucher Google ~

— Will

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx Vous pouvez rencontrer des problèmes de performances de sauvegarde si les index se trouvent sur des fichiers différents des tables qu'ils indexent (ou peut-être des lecteurs?).

— JeffO

0

C'est vraiment une mauvaise approche.

Partitionnez la table verticalement, 2 serveurs de base de données, un pour les identifiants d'utilisateurs impairs et un autre pour even, devraient bien fonctionner (les données ne sont pas liées entre les utilisateurs).

Triez les données par user_id et si ce n'est pas possible, obtenez une énorme quantité de disques RAM ou SSD.

— Slawek
source