Cela dépend de ton application.
Il peut y avoir des données dont tu te soucies peu qu'elles survivent à un reboot intempestif, et d'autres pour lesquels c'est absolument nécessaire.
Par exemple pour un serveur de messagerie, tu as deux types d'information pour chaque utilisateur : ses données permanentes (nom, carnet d'adresse, ... ) et ses données volatiles (authentifiant de session, état de présence, ...).
Comme les données volatiles sont liées à la session, et que ce sont celles auxquelles on accède en ecriture, on se soucie peu de leur survie à un reboot, et il est très interessant pour les performances de pouvoir les mettre dans une table pus rapide.
Cette dualité données permanentes/données volatiles se retrouve dans bien des cas.
[^] # Re: Oracle est loin
Posté par Barnabé . En réponse à la dépêche MySQL 5.0 : Release Candidate 1. Évalué à 8.
Il peut y avoir des données dont tu te soucies peu qu'elles survivent à un reboot intempestif, et d'autres pour lesquels c'est absolument nécessaire.
Par exemple pour un serveur de messagerie, tu as deux types d'information pour chaque utilisateur : ses données permanentes (nom, carnet d'adresse, ... ) et ses données volatiles (authentifiant de session, état de présence, ...).
Comme les données volatiles sont liées à la session, et que ce sont celles auxquelles on accède en ecriture, on se soucie peu de leur survie à un reboot, et il est très interessant pour les performances de pouvoir les mettre dans une table pus rapide.
Cette dualité données permanentes/données volatiles se retrouve dans bien des cas.