@prelude:
Oh là, j'ai relu deux fois pour comprendre, mais mauvaise idée. Scinder ainsi une table pour accélérer les accès aux données, point de vue sémantique, c'est créer deux tables réellement différentes et autonomes (par d'auto-increment commun ou de structure commune par exemple). Je ne l'ai jamais utilisé, mais MYSQL (et surement les autres SGBD) proposent du clustering, qui revient grosso modo au même système, sauf que c'est le SGBD qui le gère et non le développeur
Mais bon, ce principe de découpe suivant le modulo, c'est ni plus ni moins qu'un arbre binaire, donc, cela revient simplement à (mal) réinventer les index → A ne pas faire.
Inutile d'alléger ou d'optimiser tant que cela n'a pas été nécessaire. Ou, en anglais, early optimization is evil. Fait au plus pratique pour le développeur (toi): il faut pouvoir "piloter" chaque bâtiment indépendamment? Alors une ligne par bâtiment. Piloter uniquement par type? Une ligne par type. Piloter des deux façons? Une ligne par bâtiment → on va au plus "ciblé", et on fait ensuite des groupes, façon atomes groupés en molécules.
Si les index sont bien construits, et que les requêtes les utilisent correctement, tu pourras sans soucis gérer des tables de millions de lignes.
Le seul élément qui pourrait être limitant, suivant l'offre en ligne à laquelle tu souscris, c'est la taille limite de la BDD. Mais bon, de ce point de vue là, on est autour de 100Mo facile plutôt que 10Mo.
D'expérience, sur ECLERD, j'avais une BDD de 5Mo maximum. J'ai commencé par appliquer une structure simple mais peu optimisée pour la machine (stocker, dans la BDD, 1 ligne par age d'habitants et par région, donc ayant des habitants de 0 à 120 ans et environ 5000 régions, cela faisait 600.000 lignes). Résultat: pas de soucis en local, mais une BDD de bien 30Mo: trop lourd pour mon offre d'hébergement. La meilleure solution, là, serait de changer d'offre (mais on peut ne pas avoir envie/les moyens), ou d'optimiser, ce que j'ai fait (1 ligne / région, avec 12 colonnes, 1 par tranche de 10 ans: table réduite à moins d'1Mo).
Mais en aucun cas il ne faut optimiser avant d'avoir réellement rencontré un problème, car maintenant, je m'en mors les doigts: impossible de faire évoluer le jeu, car il a été "sur-optimisé", il est impossible d'en relire le code et encore moins de l'améliorer...
Dans le cas présent, j'aurai plus vu:
Dans l'idée: sur une planète, on a des groupes de batiments. Dans un groupe, tous les bâtiments sont identiques et font la même chose. Un groupe ne peut donc être constitués que de N bâtiments de même type, dans le même état, avec les mêmes ordres de production. On pilote les bâtiments par groupe. Si on veut, on peut scinder un groupe en deux: le groupe initial perd P bâtiments (nombre est décrémenté de P) et on crée un nouveau groupe, identique au premier (même planète, même type de bâtiment, mêmes ordres de production) sauf l'id du groupe (auto-increment) et le nombre de bâtiments (P). On a donc deux lignes en BDD, une par groupe ainsi créé. On peut donc piloter les deux groupes séparément. De façon similaire, on peut fusionner deux groupes ayant des bâtiments identiques (même type, mêmes ordres de production). Un groupe peut très bien être constitué de 1 seul bâtiment (voire de 0 bâtiment, mais cela ne fait pas trop sens...)
Oh là, j'ai relu deux fois pour comprendre, mais mauvaise idée. Scinder ainsi une table pour accélérer les accès aux données, point de vue sémantique, c'est créer deux tables réellement différentes et autonomes (par d'auto-increment commun ou de structure commune par exemple). Je ne l'ai jamais utilisé, mais MYSQL (et surement les autres SGBD) proposent du clustering, qui revient grosso modo au même système, sauf que c'est le SGBD qui le gère et non le développeur
Mais bon, ce principe de découpe suivant le modulo, c'est ni plus ni moins qu'un arbre binaire, donc, cela revient simplement à (mal) réinventer les index → A ne pas faire.
Inutile d'alléger ou d'optimiser tant que cela n'a pas été nécessaire. Ou, en anglais, early optimization is evil. Fait au plus pratique pour le développeur (toi): il faut pouvoir "piloter" chaque bâtiment indépendamment? Alors une ligne par bâtiment. Piloter uniquement par type? Une ligne par type. Piloter des deux façons? Une ligne par bâtiment → on va au plus "ciblé", et on fait ensuite des groupes, façon atomes groupés en molécules.
Si les index sont bien construits, et que les requêtes les utilisent correctement, tu pourras sans soucis gérer des tables de millions de lignes.
Le seul élément qui pourrait être limitant, suivant l'offre en ligne à laquelle tu souscris, c'est la taille limite de la BDD. Mais bon, de ce point de vue là, on est autour de 100Mo facile plutôt que 10Mo.
D'expérience, sur ECLERD, j'avais une BDD de 5Mo maximum. J'ai commencé par appliquer une structure simple mais peu optimisée pour la machine (stocker, dans la BDD, 1 ligne par age d'habitants et par région, donc ayant des habitants de 0 à 120 ans et environ 5000 régions, cela faisait 600.000 lignes). Résultat: pas de soucis en local, mais une BDD de bien 30Mo: trop lourd pour mon offre d'hébergement. La meilleure solution, là, serait de changer d'offre (mais on peut ne pas avoir envie/les moyens), ou d'optimiser, ce que j'ai fait (1 ligne / région, avec 12 colonnes, 1 par tranche de 10 ans: table réduite à moins d'1Mo).
Mais en aucun cas il ne faut optimiser avant d'avoir réellement rencontré un problème, car maintenant, je m'en mors les doigts: impossible de faire évoluer le jeu, car il a été "sur-optimisé", il est impossible d'en relire le code et encore moins de l'améliorer...
Dans le cas présent, j'aurai plus vu:
Code :
GroupesBatiments:
id_groupe, id_planete, id_type_batiment, nombre, <infos-production>
PRIMARY KEY: id_groupe
INDEX: id_planete, id_type_batiment -- si nécessaires, sinon, ne mettre aucun des deux / seulement l'un des deuxDans l'idée: sur une planète, on a des groupes de batiments. Dans un groupe, tous les bâtiments sont identiques et font la même chose. Un groupe ne peut donc être constitués que de N bâtiments de même type, dans le même état, avec les mêmes ordres de production. On pilote les bâtiments par groupe. Si on veut, on peut scinder un groupe en deux: le groupe initial perd P bâtiments (nombre est décrémenté de P) et on crée un nouveau groupe, identique au premier (même planète, même type de bâtiment, mêmes ordres de production) sauf l'id du groupe (auto-increment) et le nombre de bâtiments (P). On a donc deux lignes en BDD, une par groupe ainsi créé. On peut donc piloter les deux groupes séparément. De façon similaire, on peut fusionner deux groupes ayant des bâtiments identiques (même type, mêmes ordres de production). Un groupe peut très bien être constitué de 1 seul bâtiment (voire de 0 bâtiment, mais cela ne fait pas trop sens...)