Conseils pour la conception de bases de données dans une application Web [fermé]

Question

Quelqu'un a-t-il des astuces/conseils sur la conception de bases de données pour une application Web ?Le genre de choses qui peuvent me faire gagner beaucoup de temps et d'efforts à l'avenir lorsque/si l'application sur laquelle je travaille décolle et commence à être beaucoup utilisée.

Pour être un peu plus précis, l'application est un jeu de stratégie (basé sur un navigateur, uniquement en texte) qui impliquera principalement des joueurs émettant des "ordres" qui seront stockés dans la base de données et traités plus tard, les résultats y étant également stockés (l'historique de "commandes" et les résultats correspondants deviendront probablement assez importants).

Modifié pour ajouter plus de détails (comme demandé):

plate-forme:Django

moteur de base de données :Je pensais utiliser MySQL (sauf s'il y a un gros avantage à en utiliser un autre)

le schéma :tout ce que j'ai maintenant, ce sont quelques modèles Django, et c'est beaucoup trop de détails pour les publier ici.Et si je commence à publier des schémas, cela devient trop spécifique et je cherchais des conseils généraux.Par exemple, considérons que j'émets des "commandes" qui seront traitées ultérieurement et que je renvoie un résultat que je dois stocker pour afficher une sorte d'"historique".Dans ce cas vaut-il mieux avoir un tableau séparé pour « l'historique » ou juste un tableau qui regroupe à la fois les « commandes » et le résultat ?Je suppose que je pourrais mettre en cache la table "historique", mais cela prendrait plus d'espace dans la base de données et également plus d'opérations de base de données car je devrais constamment créer de nouvelles lignes au lieu de simplement les modifier dans la table agrégée.

Answer 1

Vous avez probablement abordé un problème beaucoup plus vaste, celui de la conception visant une évolutivité et des performances élevées en général.

Essentiellement, pour la conception de votre base de données, je suivrais de bonnes pratiques telles que l'ajout de clés étrangères et d'index aux données que vous prévoyez d'utiliser fréquemment, je normaliserais vos données en les divisant en tables plus petites et j'identifierais quelles données doivent être lues fréquemment et lesquelles doivent être lues fréquemment. écrit fréquemment et optimisé.

Bien plus importante que la conception de votre base de données pour des applications Web hautes performances, votre utilisation efficace de la mise en cache à la fois au niveau du client via la mise en cache des pages HTML et au niveau du serveur via les données mises en cache ou en servant des fichiers statiques à la place des fichiers dynamiques.

L'avantage de la mise en cache est qu'elle peut être ajoutée selon les besoins, de sorte que lorsque votre application décolle, vous évoluez en conséquence.

En ce qui concerne vos données historiques, c'est une bonne chose à mettre en cache car vous ne vous attendez pas à ce qu'elles changent fréquemment.Si vous souhaitez produire des rapports réguliers et assez intensifs à partir de vos données, alors il est conseillé de mettre ces données dans une autre base de données afin de ne pas arrêter votre application web pendant son exécution.

Bien entendu, ce type d’optimisation n’est vraiment pas nécessaire, sauf si vous pensez que votre application le justifie.

Answer 2

Normalisation de la base de données, et une bonne réflexion sur les index, sont deux choses que vous ne pouvez pas manquer.Surtout si vous considérez un jeu dans lequel les SELECTS se produisent beaucoup plus fréquemment que les UPDATE.

À long terme, vous devriez également jeter un œil à memcaché, car les requêtes de base de données peuvent constituer un goulot d'étranglement lorsque vous avez plusieurs utilisateurs.

Answer 3

Pourquoi ne publiez-vous pas le schéma que vous avez maintenant ?C'est une question trop vaste pour y répondre utilement sans quelques détails sur la plate-forme et la base de données que vous allez utiliser et la structure de table que vous proposez...

Answer 4

Tu devrais dénormaliser vos tables si vous vous retrouvez à rejoindre plus de 6 tables en une seule requête pour récupérer des données pour une page Web de type reporting qui sera souvent consultée.De plus, si vous utilisez des bibliothèques ORM comme Hibernate ou ActiveRecord, assurez-vous de consacrer du temps aux mappages par défaut qu'elles génèrent et au SQL qui finit par générer.Ils ont tendance à être très bavards avec la base de données alors que vous auriez pu obtenir les mêmes résultats avec un aller-retour vers la base de données.