MySQL: Nombre de tables ou de plusieurs bases de données?
Pour un projet, nous avons d'avoir un paquet de données qui ont toujours la même structure et n'est pas lié ensemble.
Il existe deux approches pour enregistrer les données:
- La création d'une nouvelle base de données pour chaque piscine (environ 15 à 25 tables)
- La création de toutes les tables dans une base de données et de différer la piscine par les noms de table.
Qui est plus facile et plus rapide à gérer pour MySQL?
EDIT: je ne suis pas interessed dans les problèmes de conception de base de données, je suis juste interessed dans laquelle des deux possibilités est plus rapide.
EDIT 2: je vais essayer de le rendre plus clair. Comme l'a dit nous avons des données, où certains de la date rarement appartient, ensemble, dans les différents bassins. Mettre toutes les données d'un type dans un tableau et de le lier avec un id de pool n'est pas une bonne idée:
- Il est difficile de sauvegarde/supprimer un pool (et nous nous attendons à ce que nous sommes en cours d'exécution des clés primaires après un certain temps (même lors de l'utilisation de grandes int))
Donc l'idée est de faire une base de données pour chaque bassin ou de créer un grand nombre de tables dans une base de données. 50% des requêtes sur la base de données sera simple inserts. 49% sera simple selects sur une clé primaire.
La question est, ce qui est plus rapide à manipuler pour les MySQL? De nombreuses tables ou plusieurs bases de données?
- Ne pensez-vous pas que la performance et la conception de base de données sont en quelque sorte liés?
- 99% de nos requêtes sera quelque chose comme: "SELECT * from db.tbl OÙ primaryid=x"
- Sans révéler de secrets d'affaires, pouvez-vous en détail dans la question de savoir pourquoi vous avez une conception de ce genre? Vous n'avez pas nécessairement besoin de le changer, mais de comprendre pourquoi il est comme ça pourrait l'aider.
- Les sons de poisson. Une clarification de ce que le modèle d'objet serait génial.
- Désolé, cela n'aide pas beaucoup. À moins que vous les détails de votre modèle et les exigences de plus, vous ne serez pas obtenir une réponse ici.
- Modèle: des Tonnes de données simple; Exigence: la Vitesse; la Question (la plupart d'entre vous oubliez ce): MySQL vitesse - de nombreuses bases de données contre de nombreux tableaux, peu importe comment la structure des données est!
- La Performance est basée sur beaucoup de choses, y compris l'infrastructure, comment la base de données est accessible, combien de fois il est accessible. Compte tenu de vos contraintes, je choisirais de plusieurs bases de données. Avec de multiples bases de données, vous pouvez toujours jeter un matériel à un problème.
Vous devez vous connecter pour publier un commentaire.
Il devrait y avoir aucune différence de performances significative entre plusieurs tables dans une base de données unique rapport de plusieurs tables des bases de données distinctes.
Dans MySQL, les bases de données (SQL standard utilise le terme de "schéma" pour cela) servent principalement comme un espace de noms pour les tables. Une base de données a seulement quelques attributs, par exemple, le jeu de caractères par défaut et le classement. Et que l'utilisation de
GRANTle rend pratique pour le contrôle des privilèges d'accès de données par base de données, mais qui n'a rien à voir avec la performance.Vous pouvez accéder à des tables dans une base de données à partir d'une seule connexion (à condition qu'ils soient gérés par la même instance de Serveur MySQL). Vous avez juste à qualifier le nom de la table:
Ceci est purement syntaxique différence. Il ne doit avoir aucun effet sur les performances.
Concernant le stockage, vous ne pouvez pas organiser des tables dans un fichier de base de données comme @Chris spécule. Avec le moteur de stockage MyISAM, vous avez toujours un fichier par table. Avec le moteur de stockage InnoDB, vous disposez d'un seul ensemble de fichiers de stockage qui fusionnent toutes les tables, ou bien vous avez un fichier par table (ce qui est configuré pour l'ensemble du serveur MySQL, et non par la base de données). Dans les deux cas, il n'y a pas d'avantage ou de désavantage à la création des tables dans une base de données de rapport à de nombreuses bases de données.
Il n'y a pas beaucoup de la configuration de MySQL les paramètres qui fonctionnent par base de données. La plupart des paramètres qui influent sur les performances du serveur sont à l'échelle du serveur dans le champ d'application.
Concernant les sauvegardes, vous pouvez spécifier un sous-ensemble de tableaux comme arguments à la
mysqldumpde commande. Il peut être plus pratique pour sauvegarder des ensembles logiques de tables par base de données, sans avoir à le nom de toutes les tables sur la ligne de commande. Mais il devrait faire aucune différence de performance, seule la commodité pour vous que vous entrez dans la commande de sauvegarde.Pourquoi ne pas créer une table unique pour garder une trace de vos piscines (avec un PoolID et PoolName que vous colonnes, et tout ce que vous voulez de piste), puis sur votre 15-25 tables, vous devez ajouter une colonne sur tous ce qui serait une clé étrangère dans la piscine de la table de sorte que vous savez qui la piscine cet enregistrement particulier appartient à.
Si vous ne voulez pas mélanger les données comme ça, je vous suggère de faire plusieurs bases de données. Création de plusieurs tables à tous pour la même fonctionnalité permet à mon sens d'araignée de tingle.
Si vous ne voulez pas un ensemble de tables avec poolID poolname comme TheTXI suggéré, l'utilisation des bases de données distinctes, plutôt que de multiples tableaux qui tous la même chose.
De cette façon, vous limitez la variation entre les accès des différents pools à la première "utilisation de la base de données de relevé, vous n'aurez pas à recoder votre Sélectionne à chaque fois, ou avoir du sql dynamique.
Les autres avantages de cette approche sont:
Inconvénients sont les suivants:
Je ne sais pas ce que votre demande est, mais vraiment vraiment bien réfléchir avant de créer toutes les tables dans une base de données. De cette façon, la folie réside.
Edit: Si la performance est la seule chose qui vous concerne, vous avez besoin de la mesurer. Prendre un ensemble représentatif de requêtes et de mesurer leurs performances.
Edit 2: La différence de performance pour une seule requête entre les tables de nombreux/plusieurs bases de données modèle sera négligeable. Si vous avez une base de données, vous pouvez régler l'enfer hors de lui. Si vous avez plusieurs bases de données, vous pouvez régler l'enfer hors d'eux tous.
Mon (notre? - on ne peut pas parler pour quelqu'un d'autre) le point est que, pour bien à l'écoute de la base de données(s), il y aura pratiquement pas de différence de performance entre les trois options (poolid dans le tableau, plusieurs tables, plusieurs bases de données), de sorte que vous pouvez choisir l'option qui est plus facile pour vous, dans le court ET le long terme.
Pour moi, la meilleure option est encore une base de données avec poolId, comme TheTXI suggéré, puis de multiples bases de données, en fonction de votre (principalement de l'administration) des besoins. Si vous avez besoin de savoir exactement ce que la différence de performance entre deux options, nous ne pouvons pas vous donner la réponse. Vous avez besoin de le configurer et de le tester.
Avec de multiples bases de données, il devient facile de jeter du matériel pour améliorer les performances.
Dans la situation que vous décrivez, l'expérience m'a amené à croire que vous trouverez les bases de données distinctes pour être plus rapide lorsque vous avez un grand nombre de piscines.
Il y a vraiment un principe général important d'observer ici que, bien que Ne pense pas à quelle vitesse ça va être, de profil il.
Je ne suis pas trop sûr que je comprends parfaitement votre scénario. Voulez-vous d'avoir toutes les piscines utilisant les mêmes tables, mais juste différant par un trait clé? Ou voulez-vous des piscines séparées de tables dans une base de données, avec un suffixe sur chaque table pour distinguer les piscines?
De toute façon, vous devriez avoir plusieurs bases de données pour deux raisons principales. La première étant que si vous avez à modifier le schéma d'une piscine, cela n'affectera pas les autres.
Le deuxième, si votre charge augmente (ou pour toute autre raison), vous pouvez déplacer les piscines sur les machines avec de nouveaux serveurs de base de données.
Aussi, la sécurité de l'accès à un serveur de base de données peut être plus solidement verrouillé.
Toutes ces choses peuvent encore être accomplis sans exiger des bases de données distinctes - mais la séparation va rendre tout cela plus facile et de réduire la complexité d'avoir mentalement à suivre les tables que vous souhaitez utiliser.
Différentes piscines par le nom de la table ou de les mettre dans des bases de données séparées est à propos de la même chose. Toutefois, si vous avez beaucoup de tables dans une base de données MySQL a pour charger les informations de la table et de faire un contrôle de sécurité sur toutes les tables lors de la connexion/connexion.
Comme d'autres l'ont mentionné, les bases de données séparées va vous permettre de déplacer des choses autour de vous et de créer des optimisations spécifiques à une certaine piscine (c'est à dire les tables compressées). Elle est extra admin dessus, mais il y a beaucoup plus de flexibilité.
En outre, vous pouvez toujours "la piscine" les tables dans les bases de données séparées en utilisant fédéré ou de fusionner des tableaux pour simplifier l'interrogation en cas de besoin.
Comme pour l'exécution de clés primaires, vous pouvez toujours utiliser un composé clé primaire si vous utilisez les tables MyISAM. Par exemple, si vous disposez d'un champ appelé groupCode (tout type) et un autre appelé sequenceId (auto increment) et de créer votre clé primaire comme groupCode+sequenceId. Le sequenceId s'incrémente sur la prochaine ID unique dans le groupe code.
Par exemple:
AAA 1
AAA 2
BBB 1
AAA 3
CCC 1
AAA 4
BBB 2
...
Bien qu'avec de grandes tables, vous devez être prudent sur la mise en cache et assurez-vous que le système de fichiers que vous utilisez les poignées de gros fichiers.
Je ne sais pas mysql très bien, mais je pense que je vais devoir donner à la norme de rendement réponse est "Ça dépend".
Quelques idées (traitant uniquement avec des performances/de maintenance, pas de conception de base de données):
Cependant, pour le contraste, le fait d'avoir plusieurs bases de données signifie que le serveur sera probablement utiliser plus de mémoire (car il a de multiples caches). Je suis sûr qu'il y a plus de "contre" pour le multi-approche de base de données, mais je dessine un vide maintenant.
Donc je suppose que je recommanderais le multi-approche de base de données. Évidemment, ce n'est qu'avec la compréhension qu'il peut très bien être un mieux "de la base de données designy" façon de gérer ce que vous êtes en train de faire.
Donné les restrictions que vous avez placé sur elle, je préfère faire tourner plusieurs tables dans la base de données existante, plutôt que d'avoir à se connecter à plusieurs bases de données. La gestion des chaînes de connexion ont TENDANCE à être plus fort, en plus de la gestion de la base de données différente optimisations que vous pourriez avoir.
FTR, dans des circonstances normales, je prendrais l'approche décrite par TheTXI.
En réponse à votre question, j'ai trouvé ça dépend de l'utilisation. (Flic, je sais, mais écoutez-moi.)
Une base de données unique est probablement plus facile. Vous aurez à vous soucier que d'une seule connexion et aurait encore à spécifier les tables. Plusieurs bases de données peuvent, sous certaines conditions, être plus rapide si.
Si j'étais vous, je voudrais essayer les deux. Il n'y a aucun moyen que nous serons en mesure de vous donner une réponse utile.