Aide pour une valeur maximale

[Nov@_]

Bonjour,
Je souhaiterais fixer une valeur maximale dans mon jeu de simulation de vie pour un INT, allant de 0 à 100 (0 étant la valeur minimale et 100 la valeur maximale), comment puis-je faire pour ne pas les dépasser.

Merci d'avance !

[niahoo]

Utiliser la fonction min ?

[Xenos]

Salut,

• T'as la solution bouseuse à base d'ENUM (un ENUM de 0 à 100), hyper-lourd mais fonctionnel.
• T'as la solution vaseuse à base de checks coté client (ton code client, ie PHP ou autre, se charge de vérifier que la valeur est entre 0 et 100).
• T'as la solution bancale des clefs étrangères: tu fais une table avec une seule colonne "valeur" de 101 lignes (de 0 à 100) et tu fais une clef étrangères depuis la table contenant les valeurs à restreindre vers cette table d'entiers (lourds, mais extensible, centralisé, sans trigger).
• T'as la solution à coup de TRIGGER (un trigger "BEFORE UPDATE" qui vérifie que la valeur est entre 0 et 100, si non, le TRIGGER fait un SIGNAL pour arrêter l'opération).
• T'as la solution d'une procedure, au lieu de passer par la query; elle peut alors vérifier que la valeur est dans l'intervalle fixé avant de faire l'insert/update (et si elle n'est pas dans l'intervalle, pouf, SIGNAL)

Moi, j'irai sur les TRIGGER ou PROCEDURE, car cela me semble parfaitement adapté (à défaut d'avoir des syntaxes CHECK en MySQL).

[niahoo]

Un trigger pour borner un integer ?

Si tu es en PHP :

class Personnage {

    const MAX_HP = 100;



    function setHP($val) {

        $this->attributes['HP'] = min($val, self::MAX_HP);

    }

}

[Xenos]

Sauf que quand t'as 4 clients possibles de la même BDD, tu ne peux faire ce genre de check coté client (d'autant plus quand l'un est PHP, l'autre Java, l'autre C#). Soit tu fais faire le check par la BDD (cela me semble logique pour moi de laisser le SGBD faire les checks d'intervalles et de contraintes), soit tu te crées un proxy qui sera le seul code client (et tous les autres doivent passer par ce proxy, j'te dis pas la misère que cela finit par être niveau a-standardisation).

Mais bon, j'ai pas évincé cette solution pour autant, je la trouve seulement vaseuse: si on fait le check "entre 0 et 100" coté client, pourquoi ne pas faire les checks des clefs étrangères coté client?!

[niahoo]

Pardon je ne savais pas que le jeu tournait sur trois serveurs à la fois, l'un en PHP, l'un en Java et le dernier en C#. Je trouve que c'est une très mauvaise idée.

Mais du coup, vu que au final tout est stocké en base, pourquoi ne pas implémenter directement le jeu avec des triggers, des procédures, etc ?

Je crois qu'on s'est compris. Mais pour te répondre quand même : un trigger c'est moins facilement portable qu'un clé étrangère, et c'est surtout totalement overkill pour un foutu integer.

[Xenos]

Perso, je ne prends pas en compte ce genre de considération de performances (encore moins dans le cadre d'un jeu web, car le serveur est souvent bien largement surdimensionné par rapport au trafic). Je préfère procéder comme les échappements HTML, json, SQL ou autre: si c'est une contrainte portant sur les données, pouf, je fous ça coté SGBD. Ce ne sera qu'une fois que les performances deviendront un problème (ou qu'un autre problème apparait) que j'envisagerai de déplacer cela ailleurs (si le problème de perfs vient de là).

Du coup, oui, la logique du jeu est dans le SQL (Fat Models, Skinny Controllers).

En revanche, pourquoi un trigger serait-il "moins facilement portable qu'une clef étrangère"?

[Roworll]

Il y a une autre option mais elle dépend du SGBD.
Mysql 5.7 et MariaDB 5.2 supportent les colonnes calculées.

Il suffit de créer la colonne avec une valeur de LEAST(<colonne source>,100).
A voir après si la colonne reste virtuelle ou doit être matérialisée (Virtual ou Persistent/Stored) en fonction de l'usage qu'on veut en faire.

[niahoo]

Du coup, oui, la logique du jeu est dans le SQL (Fat Models, Skinny Controllers).

Donc déjà pour info « le SQL » désigne un langage, on parle plutôt de SGBDR ici, mais ensuite le code que j'ai donné est bien un model et pas un controller. Même si ton slogan me fait penser à une vision qui a un peu du mal à se sortir du MVC, on est à peu près d'accord.

En revanche, pourquoi un trigger serait-il "moins facilement portable qu'une clef étrangère"?

La syntaxe des FK est assez standard, alors que les syntaxe des blocs peut changer d'un SGBDR à l'autre. Ensuite tu parlais de faire des checks côté client, c'est stupide. Et côté serveur, on les fait les checks dans le code en fait : par exemple pour ajouter dans un inventaire on va généralement charger l'inventaire. Et c'est aussi vrai si tout est codé en PL/SQL sauf que c'est automatique du coup.

[Nov@_]

Je suis en PHP, et j'ai tout simplement fait une condition, et ça fonctionne, merci pour vos réponses.