Tout d'abord, vous concevez une application à l'envers. Les données pilotent l'interface utilisateur, et non l'inverse.
cela ne devrait pas avoir d'importance du tout si vous avez des listes déroulantes mois/année ou non. QU'EST-CE QUE VOUS AVEZ BESOIN DE CAPTURER ?
Si chaque valeur est pour un seul mois, alors pourquoi s'embêter avec la date de début et de fin ? Utilisez une date et une convention du premier du mois ou du dernier du mois.
6/1/2010 est l'entrée de JUIN 2010. Le jour n'a pas d'importance. N'utilisez rien d'autre qu'un type de date.
Si vous normalisez le schéma, vous avez besoin d'une table pour le site de médias sociaux, une table de propriétés, une table enfant pour les deux qui a une colonne de date pour Count_for_month et une colonne d'entiers pour count_of_followers.
Réponse à Marjan
Vos données sont la seule chose qui compte. Si Excel disparaissait, cela vous dérangerait-il tant que les données contenues dans les fichiers pourraient être utilisées dans Google Docs ?
Mais cela signifie-t-il que je recommande de capturer beaucoup de données inutiles ? Ou concevoir un écran par table ? (Je devine juste ce que l'on entend par "table et CRUD centré") Je ne dis pas non plus que votre modèle de données n'est pas guidé par des exigences, mais l'idée que OUTPUT est la seule raison pour laquelle votre système existe est une folie.
