Je fais cette base de données de base de données pour un système où je dois stocker des tableaux de longueur variable dans la base de données MySQL.
La longueur des tableaux sera (au plus) en centaines, voire des milliers.
De nouveaux tableaux seront créés régulièrement, peut-être des dizaines quotidiennes.
clarifier, 1. Moyenne grossièrement et 2. Learr_values être utilisé comme des tableaux interrogés en rejoignant une matrice complète.
Des idées sur les raisons pour lesquelles une approche est meilleure que d'autres?
4 Réponses :
beaucoup de rangées dans quelques tables. Faire une nouvelle table pour chaque nouvelle structure / enregistrement est absolument incorrect et le même moyen d'utiliser une base de données relationnelle.
En fait, presque à tout moment, votre code crée de manière dynamique des tables, vous faites quelque chose de terriblement, terriblement faux.
D'accord. Les tables et les types de lignes ("colonnes") doivent toujours être corrigés dans le code, sauf si vous codez une autre phpmyadmin. Haha :)
Cela serait-il toujours correct si j'avais 1 million de nouvelles lignes chaque semaine?
@Abatonime Oui, ce serait surtout correct. Quelle est l'alternative que vous envisagez? un million de nouvelles tables chaque semaine?
Qu'en est-il de 100 000 entrées par catégorie par semaine, sans nombreuses informations communes avec des entrées dans différentes catégories. Environ 100 nouvelles catégories chaque semaine.
@Silverringvee Oui, toujours et pour toujours, beaucoup de rangées, peu de tables. Peu importe le type de données que vous stockez ou à quel point je vais le répéter: Si vous créez des tables de manière dynamique, vous faites quelque chose de mal. 100k entrées par semaine est rien . Chaque système DBMS jamais construit devrait être capable de gérer cela sans percer la sueur.
Comme pour toutes les réponses à ce type de questions, cela dépend toujours quelque peu de ce que votre résultat final doit être, mais personnellement, je favoriserais toujours une table unique sur des tables créées dynamiquement - cela permet de poser beaucoup plus de questions plus simples. Il le rend aussi un peu plus simple (je pense) lorsque vous examinez le schéma de la base de données - plusieurs milliers de tableaux peuvent faire de la recherche de ce dont vous avez besoin lorsque vous accédez directement à la base de données un peu plus facile.
En outre, si vous trouvez que vous avez besoin d'étendre votre «tableau» à un moment donné avec un autre champ, cela signifie qu'il y aura une table de base de données unique pour modifier, plutôt que beaucoup.
Augmentez le nombre de tables jusqu'à ce que le schéma soit normalisé (a très peu ou pas de redondance / duplication). N'augmentez pas le nombre de tables au-delà et être prudent de l'ajout d'une nouvelle table pour la performance (bases de données modernes, à quelques exceptions près que vous ne le pensez), ou pour faire face aux cas de bord, tels que la duplication qui se produit une fois par la vie de l'application, ou pour <1% des lignes.
Il serait également plus facile de comprendre votre question si nous connaissions le domaine de la question - sont ces adresses, clients, livres ou quoi?
Il me semble que chaque gamme de données a un schéma distinct. Avez-vous envisagé d'utiliser une base de données NOSQL? Il sera beaucoup plus facile de travailler avec, à mon avis.
Si vous devez coller avec MySQL, vous voulez absolument aussi peu de tables que possible. Basé sur ce que vous avez présenté, vous pouvez avoir une table avec trois colonnes - et, si vous avez besoin de plusieurs copies du même tableau "TYPE", ajoutez une instance colonne aussi.
10 enregistrements par jour n'est pas très important, ce n'est que 3 750 enregistrements par an, j'ai une demande qui obtient environ 1 000 nouveaux enregistrements par jour à une seule table importante et complexe, le total de nouveaux enregistrements est d'environ 1 200 par jour à cette application. dans toutes les tables. N'oubliez pas qu'il n'est pas inhabituel qu'un DB MySQL ait des millions de lignes. En raison de la nature variable des données que vous avez, avez-vous pensé si votre application pourrait mieux fonctionner avec un dB comme MongoDB qui n'a pas de schéma? C'est un dB orienté objet, mais peut valoir un coup d'œil en fonction de votre application.
10 serait un sous-estimateur mais disons 80 nouveaux tableaux par jour contenant 3000 valeurs en moyenne. Cela ferait plus de 11 millions de lignes chaque année. Ou environ 3750 tables avec 3000 lignes en moyenne.
11 millions sont grandes mais toujours gérables, si cette application doit être utilisée à long terme, pensez à l'évolutivité et à ce que DB est le meilleur pour votre application. Je penserais aux alternatives si j'étais vous.
@Plane Les bases de données sont conçues pour conserver beaucoup de lignes. Il ne compte littéralement pas du tout à quel point votre ensemble de données est important, il y a NO gain pour le diviser dans des ensembles de données «plus petits» en le divisant dans de nombreuses tables et de nombreux inconvénients.