Dev Faq
7
votes

Y a-t-il une limitation du nombre de tables qu'une base de données PostgreSQL peut avoir?

J'ai créé une base de données dans PostgreSQL, appelons-le Testdb .

J'ai un ensemble générique de tables dans cette base de données, xxx_table_one , xxx_table_two et xxx_table_three . .

Maintenant, j'ai du code Python où je veux créer et supprimer de manière dynamique des "jeux" de ces 3 tables sur ma base de données avec un identifiant unique dans le nom de la table distinguant différents "ensembles" les uns des autres, par exemple.

SET 1
testdb.aaa_table_one
Testdb.aaaa_table_two
testdb.aaa_table_three

Set 2
testdb.bbb_table_one_one
testdb.bbb_table_two
testdb.bbb_table_three

La raison pour laquelle je veux le faire de cette façon est de garder plusieurs grandes collections de données de données connexes séparées les unes des autres. J'ai besoin de remplacer régulièrement les collections de données individuelles et il est facile de déposer le tableau des collections de données et de recréer un nouvel ensemble de tables complète. De plus, je dois mentionner que les différentes collections de données s'inscrivent dans les mêmes schémas. Je pourrais donc enregistrer toutes les collections de données dans 1 série de tables à l'aide d'un identifiant pour distinguer les collections de données au lieu de les séparer en utilisant des tables différentes.

Je veux savoir, quelques éléments

  1. PostgreSQL limite le nombre de tables par base de données?
  2. Quel est l'effet sur la performance, le cas échéant, d'avoir un grand nombre de tables dans 1 base de données?
  3. Quel est l'effet sur les performances de la sauvegarde des collections de données dans différents ensembles de tables par rapport à la sauvegarde dans le même ensemble, par exemple. Je suppose que je devrais écrire plus de requêtes si je veux interroger plusieurs collections de données à la fois lorsque les données sont diffusées des tables d'accrocs, par rapport à 1 ensemble de tables.
6 commentaires

Définir "grand". La création et la chute des tables sont généralement la mauvaise approche à prendre.

Faire. Pas. Faire. Cette. C'est un hack terrible design. Beaucoup de gens l'essaient - tous ceux qui l'essuient la regrette. Utilisez des valeurs de clé comme des colonnes à l'intérieur des tables; Ne créez pas de tables comme ceci.

Important pourrait être d'environ 1 000 000 - 10 000 000 enregistrements. Pas si grand, mais chaque collection de données est une collection de données pré-traitée mise à jour une ou deux fois par mois.

Merci s.lott. Pourriez-vous s'il vous plaît élaborer un peu sur les pièges de cette décision de conception? Très appréciée.

Les noms de table générant de manière dynamique sont chers. Ralentir. Difficile. Vous devez construire (et analyser et exécuter) des déclarations SQL qui ne sont pas toutes similaires. Mettre les valeurs de clé dans une colonne est peu coûteuse. Rapide. Simple. Vous ne faites que mettre des valeurs dans des déclarations SQL pré-analysées et prêtes à exécuter avec de nouvelles valeurs. Ne créez pas de noms de tableaux de manière dynamique.

Après avoir lu ce fil, j'ai trouvé le lien suivant utile: wiki.postgresql.org/wiki/don't_do_this

3 Réponses :

3
votes
  1. PostgreSQL n'impose pas une limite directe à ce sujet, votre système d'exploitation (cela dépend de la taille du répertoire maximale)
  2. Cela peut dépendre de votre système d'exploitation. Certains systèmes de fichiers sont plus lents avec de gros répertoires.
  3. PostgreSQL ne sera pas capable d'optimiser les requêtes si elles sont à travers différentes tables. Ainsi, en utilisant moins de tables (ou d'une table unique) doit être plus efficace
0 commentaires
14
votes

PostgreSQL n'a pas beaucoup de limites, votre matériel est beaucoup plus limité, c'est là que vous rencontrez la plupart des problèmes. http://www.postgresql.org/about/

Vous pouvez avoir 2 ^ 32 tables dans une seule base de données, un peu plus de 4 milliards.

1 commentaires

La conclusion mentionnée dans cette réponse est un crédit d'une recherche d'un contributeur communautaire PostgreSQL Voir PGCON 2013

0
votes

Si vos données n'étaient pas liées, je pense que vos tables pourraient être dans différents schéma, puis vous utiliseriez Set Search_Path vers Schema1, Public Par exemple, de cette façon, vous ne seriez pas à dynamiquement Générez des noms de table dans vos questions. Je prévois d'essayer cette structure sur une grande base de données qui stocke des journaux et d'autres informations de suivi.

Vous pouvez également modifier votre tablespace si votre système d'exploitation a une limite ou souffre de la taille de la grande répertoire.

0 commentaires

Articles qui pourrait vous intéresser :

Laravel whereRaw - comment échapper à un '?'
Pgadmin ne se charge pas
Interroger les données de PostgreSQL à partir de deux tables
Erreur: impossible d'insérer plusieurs commandes dans une instruction préparée