11-08-2013, 03:29 PM
Bien sûr, l'usage abusif de sérialisation est à proscrire. Celui que je décris — qui utilise un mécanisme de la base de données (le type hstore de PostgreSQL, transparent à l'utilisation) est plutôt sain.
L'application sera hébergée sur du dédié, je peux me lâcher sur le stockage.
Par ailleurs, je ne compte pas avoir des tonnes de ressources (la dizaine que j'évoque me semble un bon maximum), et je doute en rajouter souvent par la suite.
Je n'utiliserais les ressources que pour des résolutions ponctuelles, notamment à chaque changement d'heure. Puis par plus petites touches pour de l'affichage.
Je ne sais pas à quel point ce que tu décris concernant les équations mathématique me concerne (ce n'est vraiment pas un milieu dans lequel je suis à l'aise).
La densité des informations sera assez importante puisque la plupart des bêtes peuvent toucher un peu à tout. Donc je pense qu'il n'y aura peu de gâchis.
Après renseignement, les NULL ne coûtent presque rien dans PostgreSQL (gratuit pour une table jusqu'à 8 colonnes, puis 8 octets par tranche de 64 colonnes). Le stockage étant bon marché, il est plus intéressant de favoriser des colonnes NULL que des jointures.
D'ailleurs, pour ceux que ça intéresse, voici le lien vers le coût des NULL dans MySQL. Le fonctionnement des tables InnoDB (utilisé par défaut depuis MySQL 5.5) se rapproche de PostgreSQL (les NULL ne coûtent presque rien). C'est plus coûteux avec MyISAM.
Merci Xenos pour tes réponses : c'est analytique, c'est sympa.
L'application sera hébergée sur du dédié, je peux me lâcher sur le stockage.
Par ailleurs, je ne compte pas avoir des tonnes de ressources (la dizaine que j'évoque me semble un bon maximum), et je doute en rajouter souvent par la suite.
Je n'utiliserais les ressources que pour des résolutions ponctuelles, notamment à chaque changement d'heure. Puis par plus petites touches pour de l'affichage.
Je ne sais pas à quel point ce que tu décris concernant les équations mathématique me concerne (ce n'est vraiment pas un milieu dans lequel je suis à l'aise).
La densité des informations sera assez importante puisque la plupart des bêtes peuvent toucher un peu à tout. Donc je pense qu'il n'y aura peu de gâchis.
Après renseignement, les NULL ne coûtent presque rien dans PostgreSQL (gratuit pour une table jusqu'à 8 colonnes, puis 8 octets par tranche de 64 colonnes). Le stockage étant bon marché, il est plus intéressant de favoriser des colonnes NULL que des jointures.
D'ailleurs, pour ceux que ça intéresse, voici le lien vers le coût des NULL dans MySQL. Le fonctionnement des tables InnoDB (utilisé par défaut depuis MySQL 5.5) se rapproche de PostgreSQL (les NULL ne coûtent presque rien). C'est plus coûteux avec MyISAM.
Merci Xenos pour tes réponses : c'est analytique, c'est sympa.