Disons que vous créez une base de données pour stocker des messages pour une application de salle de discussion. Il y a un nombre infini de salles de discussion (ils sont créés à la demande d'exécution à la demande) et tous les messages doivent être stockés dans la base de données.
Ce serait une erreur confondue à créer une table géante pour stocker des messages pour toutes les salles de discussion, sachant qu'il pourrait éventuellement être des milliards d'enregistrements dans une table?
serait-il plus prudent de créer de manière dynamique une table pour chaque chambre créée et de stocker les messages de cette pièce uniquement dans cette table?
4 Réponses :
Il serait approprié d'avoir une seule table. Lorsque vous avez n tables qui poussent par l'utilisation de l'application, vous décrivez à l'aide de la base de données elle-même comme une table de tables, ce qui n'est pas la manière dont une RDBM est conçue pour fonctionner. Des milliards d'enregistrements dans une seule table sont triviaux sur une base de données moderne. À ce niveau, vos seules préoccupations de performance sont de bons index et de la manière dont vous faites des jointures.
Pour ajouter à cette réponse ... Vous pouvez également fédérer une table en fonction de la dimension. Donc, comme mécaniquement, on ressemble et fonctionne comme des tables séparées, mais est liée de manière transparente ensemble à l'aide d'index. Encore une fois, plus d'informations de l'OP sont nécessaires.
tandis qu'une table par salle de discussion pourrait être effectuée, chaque base de données est limitée par rapport au nombre de tables pouvant être créées, donc compte tenu d'un nombre infini de salles de discussion, vous devez créer un nombre infini de tables, ce qui n'est pas aller au travail.
Vous pouvez sur l'autre main magasin des milliards de lignes de données, le stockage n'est normalement pas le problème étant donné que la récupération spatiale des informations dans une période sensible est toutefois et nécessite une planification minutieuse.
Vous pouvez partitionner les messages par une plage de dates et, si vous êtes planifié, vous pouvez utiliser la migration LUN pour déplacer des données plus anciennes sur le stockage plus lent, tout en laissant des données plus récentes sur le stockage plus rapide.
milliards d'enregistrements?
En supposant que vous avez constamment 1000 utilisateurs actifs avec 1 message par minute, cela se traduit par des messages de 1,5 Mio par jour et environ 500 mio messages par an.
Si vous avez toujours besoin de stocker des messages de discussion de plusieurs années (que pour?), vous pouvez les archiver en tables basées sur l'année.
Je ferais certainement discuter de la création dynamique de tables à base de chambres.
D'accord. Pourquoi auriez-vous besoin d'une base de données pour vous connecter? Utilisez simplement un fichier .txt pour archiver les chats. Je suppose que vous auriez besoin des journaux pour des raisons degal, c'est pourquoi vous avez probablement pensé à une base de données. Une utilisation du système de fichiers serait bien meilleure si vous n'avez pas besoin de faire des opérations de lecture.
Désolé les gars, mais ne pensez pas si littéralement. Ce n'est pas le scénario actuel, mais la prémisse est la même. Supposons des milliards de documents, quel que soit le scénario que vous pourriez imaginer.
Strictement parlant, votre conception a raison, une table unique. Champs avec entropie basse {E.G 'UserID' - Vous souhaitez créer un lien à partir de tables d'identité, c'est-à-dire après les modèles normaux de normalisation de la base de données}
Vous voudrez peut-être réfléchir à la partition basée sur la plage. E.G 'Copies' de votre table avec un préfixe d'un an. Ou peut-être même une table juste «actuelle» et archive
Ces deux approches signifient que votre requête Sémantic est plus complexe {Considérez si quelqu'un a effectué une recherche pluriannuelle}, vous devriez interroger plusieurs tables.
Cependant, la hausse est que votre table «actuelle» restera à une taille approximativement constante et l'archivage est plus simple. - {Vous pouvez simplement déposer la table 2005_chat lorsque vous souhaitez archiver les données 2005}
-Aace
Vous voudrez peut-être élaborer sur vos cas d'utilisation. High écris? Quel type de lit? Étant donné aucune autre information, une table est la "la plus correcte". Mais comment cela se produit dans le monde réel est une question totalement séparée. Et vous n'avez aucune information concernant que les personnes répondent avec précision.