Nettoyage de base de donnée

[Ter Rowan]

tu te trompes kassak

la manière manuelle c'est justement le risque d'oublier des choses (quand y a dix tables, ça va, quand y en a 100... entre la fatigue, le coup de fil d'un pote, la panne électrique, msn qui clignote,etc... c'est vite fait d'oublier)

la manière automatique c'est aussi ce risque (si on a oublié une relation dans le modèle), mais aussi celui d'en faire trop

c'est très justement ce qu'explique Roworll (mais bon quand on a row dans son nom on ne peut qu'avoir raison faut p as s'étonner)

n'empêche, je serais malgré tout plus favorable de le faire à la manuelle ^^

[keke]

Coucou,

Réponse mitigé ... pour ma part aussi ^^.

Utilisant Mysql pour mon jeu, j'ai des scripts fait à la main qui :
Nettoie les données en erreur (en remontant ces erreurs sous forme de MP dans le jeu). Cela a l'avantage d'avoir un jeu relativement propre (pas de lien rompu entre les données ... enfin pas trop longtemps) et de garder une trace de l'information

Utilisant Oracle pour le boulot, j'ai des procédures basés sur des clés primaires et étrangère pour valider et signaler les erreurs. Bilan, il est pratiquement impossible de faire des modifications impliquant des liens en base ... ce qui est particulièrement dérangent. Cela dit, on n'est pas sensé faire ce type de modification, il n'y a donc pas de raison que l'on soit aidé sur ce thème.

Ces 2 méthodes ont leurs travers ... la première est utile pour le développement, la deuxième pour la production (les VRAI jeux)
Kéké.

[Cartman34]

Je préfère faire une requête de 0.000300 secondes plutôt que 30 de 0.000200 secondes...
De plus, je ne sais pas vous mais je n'ai fais que des jeux avec une production, donc il fallait toujours recharger le compte, les construction et ressources (et donc la planète ou la ruche) à chaque page.
Donc je ne vois pas pourquoi j'aurais tout séparer, après tout dépend des données que vous voulez entrer...
Après tout dépend de ce que vous entendez par la séparation car nous avons quand même 18 tables pour IGame et MielWar chacun.
Il n'y a qu'au niveau des points que cela peut poser problème, mais il faut savoir qu'une requete sélection tout les champs d'une table pour une entrée sera aussi longue si cette table contient 5 champs que si elle en contient 30...ça tourne souvent autour de 0.000300 secondes(Testé et approuvé sur pma !) et en sélectionnant la configuration + le compte du joueur + la planète du joueur, ca fait environ un millième de sec., ce qui est très faible.

Ter Rowan-> ecret: Si tu ne testes pas tes scritps dans tous les cas, cela ne sert à rien de développer :glace:.

[Ter Rowan]

Ter Rowan-> ecret: Si tu ne testes pas tes scritps dans tous les cas, cela ne sert à rien de développer :glace:.

cette remarque ne tient pas :

si tu oublies qu'une table est impactée par la suppression d'un joueur, tu oublieras aussi de tester si ton script impacte ou non cette table


ce n'est pas comme une recherche de bug

que se passe t il si les ressources d'un joueur restent en bdd alors que le joueur a disparu ? strictement rien, aucun bug

je parle d'oubli d'élément pas de on teste ou pas quelque chose auquel on a pensé

[Cartman34]

Les ressources de mes jeux sont actuellement dans la tale des planètes/ruches...donc pas de problème...
Et puis quand j'ai fais la fonction gérant cela, j'ai pris les table une par une dans l'ordre d'affichage dans pma et j'ai regardé s'il y avait des données à supprimer, ca fonctionne bien.

[phenix]

Il est bien entendu qu'il faut regrouper dans les même tables les informations qui vont ensemble.

Mais sa ne sert à rien de grouper 2 choses qui n'ont rien a voir ensemble simplement pour gagner de la place...

[Cartman34]

Ce n'est généralement pas la place qui manque sur un serveur, nous n'utilisons par exemple qu'1/20 de la capacité de mon hébergement qui est réduit en capacité intentionnellement.
Si on peut occuper plus de place pour gagner en performance, il y a tout à y gagner.

[phenix]

Si on peut occuper plus de place pour gagner en performance, il y a tout à y gagner.

Selon moi, une base de donnée correctement réalisé n'a pas besoin de ce genre d'artifice.

M'enfin, avec les machines actuel, on s'en fou un peu...

Cela dit, ce n'est pas vraiment l'objet de la discutions :good:

[Roworll]

Je préfère faire une requête de 0.000300 secondes plutôt que 30 de 0.000200 secondes...
De plus, je ne sais pas vous mais je n'ai fais que des jeux avec une production, donc il fallait toujours recharger le compte, les construction et ressources (et donc la planète ou la ruche) à chaque page.

Disons que cela dépend évidemment de ton modèle de données.
Mais autant utiliser la puissance des moteurs relationnels et éviter les tables avec une structure du type
joueur_id
planete_id1
planete_id2
planete_id3
etc
(Ceci dit, je ne connais pas ton modèle, je me base juste sur des exemples de modélisation rencontré IRL)

mais il faut savoir qu'une requete sélection tout les champs d'une table pour une entrée sera aussi longue si cette table contient 5 champs que si elle en contient 30...ça tourne souvent autour de 0.000300 secondes(Testé et approuvé sur pma !) et en sélectionnant la configuration + le compte du joueur + la planète du joueur, ca fait environ un millième de sec., ce qui est très faible.

Plus ton recordset devra renvoyer de champs, plus le traffic sera important. C'est pour cela qu'on essaye d'éviter le SELECT * au maximum, afin d'e ne pas récupérer de données parasites et de gaspiller des ressources.
Ensuite, attention à la charge du serveur.
Les systèmes de verrous internes au moteur de base de données utilisé peut amener des problèmes de performances rapidement et en général, c'est exponentiel.
La ou 10 joueurs connectés simultanément verront s'exécuter leur requête en 0.0003 secondes; 100 joueurs frôleront peut être la seconde.
Faire des test en local, tout seul sur son serveur c'est bien. Faire des tests de charge avec accès concurrentiels, c'est mieux (et ça réserve souvent des surprises).

M'enfin, avec les machines actuel, on s'en fou un peu...

Mmm pas vraiment.
Bossant dans un environnement de production avec plein de bases de données dedans, je peux certifier qu'une base développée avec les pieds est capable de foutre à genoux un serveur performant via des opérations simples.

Pensez donc aux index, aux verrous, aux transactions, etc. La base de données n'est pas un élément à traiter à la légère, que ce soit au niveau de la conception ou de l'utilisation.
Je prends un exemple sous SQL Server 2000.
Une page dans ce SGDB fait 8192 octets. 96 octets sont utilisés pour la gestion ce qui laisse 8060 octets par page pour le stockage.

Supposons que vous fassiez une table avec un enregistrement de 4050 octets.
Et bien chaque enregistrement prendra une page a lui tout seul car le SGDB sera incapable d'en mettre deux dans la même page (4050 * 2 = 8100 ce qui est supérieur aux 8060 disponibles par page)
Du coup environ 50% de l'espace sur la table sera réservé mais inutilisé.

Beaucoup de problèmes de performances sur les applications sont imputés à la base de donnée. C'est vrai. Mais 80% de ces problèmes viennent d'une application mal foutue et/ou d'une analyse biaisée.

[QuentinC]

J'entre dans ce topic avec un HS, mais :

Faire des tests de charge avec accès concurrentiels, c'est mieux (et ça réserve souvent
des surprises).

Concrètement, vous faites des tests de ce genre comment ?