plus de table ou plus de lignes mieux en sql?

Question

En fait, je suis la construction d'un logiciel pour les institutions académiques, donc je voulais juste savoir les réponses de quelques questions:

Comme vous le savez les nouvelles données seront générées chaque année (pour les nouvelles admissions) et certains seront modernisés . Donc, je devrais stocker toutes les données dans un seul tableau avec la séparation année académique (comme une colonne comme ac_year), ou devrais-je faire des tableaux séparés pour chaque année. Aussi qu'il existe différentes tables pour stocker des informations telles que, classes, marques, frais, auberge, etc à propos des étudiants. Donc, chaque info, comme frais seraient stockés dans des tables comme Fee 2010 Fee 2011 Fee 2012 ...

Ou en 1 seule table d'honoraires avec une année en tant que colonnes. Un autre point est que bientôt après 1-2 ans, la base de données deviendra plus lourde, donc la sauvegarde des données pour une seule année serait possible dans un seul tableau (comme Frais avec l'année comme une colonne)?

Et S'il vous plaît répondre gardant à l'esprit SQL Server 2005.

Merci

Answer 1

Ce n'est pas typique de stocker les données dans plusieurs tables en fonction des contraintes de temps. Je préférerais tout stocker dans une seule table. À l'avenir, vous pouvez envisager d'archiver les anciennes données, mais il faudra encore beaucoup de temps avant que la performance devienne un problème.

Answer 2

Il est toujours préférable d'ajouter une nouvelle propriété à l'entité plutôt que de créer une nouvelle entité pour chaque propriété différente. De cette façon, la maintenance et l'interrogation seront beaucoup plus faciles pour vous. Dans la partie performance de l'interrogation, vous n'avez pas à vous soucier des affaires internes des données et de la base de données. S'il y a un vrai problème de performance, il existe de nombreuses solutions comme Créer un indice sur des années comme dans votre situation.

Answer 3

En répondant à la question, la réponse est clairement de stocker les données dans une table, avec l'année (ou la date ou toute autre information) sous la forme d'une colonne. C'est simplement la bonne chose à faire. Vous traitez avec la même entité au fil du temps.

La seule exception serait lorsque les champs changent de manière significative d'une année à l'autre. Je doute que ce soit le cas pour votre table.

Si votre base de données devient vraiment volumineuse, vous pouvez envisager de partitionner la table en fonction du temps. Chaque partition constituerait la valeur d'une année de données. Cela permettrait d'accélérer les requêtes qui ont seulement besoin d'accéder à la valeur d'une année. Cela aide également à sauvegarder et à restaurer les données. C'est peut-être la solution que vous cherchez en fin de compte. "Vraiment grand" signifie au moins des millions de lignes dans la table. Même avec quelques millions de lignes dans la table, la plupart des requêtes fonctionneront probablement correctement sur du matériel décent avec des index appropriés.