Typage des variables MySQL via PHP

Question

Bonjour,

Je navigue sans gros problème pour la conception d'un gestionnaire de BDD utilisant Flash pour l'appel des  données, PHP pour la transcription et MySQL pour stocker.
Objectif: lier des paramètres d'animations techniques avec les données stockées.

Question:
En créant une BDD, je souhaite typer mes variables:
exemple : nomMoteur -> text
          coupleFrein -> integer
          ViscositeHuile -> Float
          etc...

Ma question est très simple:
Quelle est la commande php (si elle existe) qui permette de définir le type de variable (text, real, integer, float, etc...) dans MySQL afin de définir les champs de mes tables, dans le genre...

mysql_field_type(...)='text' ???

Je n'ai pas trouvé dans les listes  de forums, et si j'ai mal lu, que je sois puni à boire une bonne bière à Noel !

Merci !

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

tpoinsot · Answer

Salut,
il faut faire une requête SQL "CREATE TABLE ..." et tu pourras définir tes champs.

thip

cs_danbo · Answer

!a n'y est, j'ai trouvé,

Merci à tous.
Il suffisait de chercher !

J'ai vu du style 

is_float, is_interger, is_text etc...


Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

kohntark · Answer

Salut,

Je n'ai pas trouvé dans les listes de forums, et si j'ai mal lu, que je sois puni à boire une bonne bière à Noel !
 Tu ne prends pas de risque a définir toi même ta punition, j'dirais plutôt "3 McDo et 1 litre de Coca" pour que ça en soit une vraie.

Pour compléter un peu le propos de Tpoinsot, c'est au niveau de la table MySQL que le typage doit être fait. Côté PHP ça n'a guère d'importance, il s'en débrouille (pour info).



Cordialement,

Kohntark -

kohntark · Answer

J'ai loupé ton dernier message ...

Les fonctions que tu énonces ne permettent pas de "définir le type de variable", mais de le connaitre.


Kohntark -

cs_danbo · Answer

kohntart,

merci pour l'info, mais dis m'en plus.

lorsque tu dis que (je cite):

"Pour compléter un peu le propos de Tpoinsot, c'est au niveau de la table MySQL que le typage doit être fait. Côté PHP ça n'a guère d'importance, il s'en débrouille (pour info). "

Est-ce que cela signifie que le "débrouille" c'est un php qui analyse et sait de quelle type de variable il s'agit ?
Et si c'est vrai, est-ce que cela ne fait pas perdre de temps au processeur, surtout si des milliers de valeurs sont à traiter ?

merci 

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

kohntark · Answer

mais dis m'en plus
Toi aussi !!! 
Quel est le but exact (typage des variables) ? Rencontres tu des erreurs ?

Est-ce que cela signifie que le "débrouille" c'est un php qui analyse et sait de quelle type de variable il s'agit ?
Oui, en théorie.

Contrairement à bien d'autres langages PHP est très faiblement typé, ce qui est dans la majorité des cas un avantage ( je vais en faire bondir certains)
Dans la majorité des cas (bis) il est inutile de spécifier le type à PHP. Quand cela est nécessaire il suffit de le faire conformément au lien cité dans mon précédent post.

Et si c'est vrai
Oui, ça l'est, si je mens que je sois puni à boire un quadruple scotch de 12 ans d'âge à Noël.

est-ce que cela ne fait pas perdre de temps au processeur, surtout si des milliers de valeurs sont à traiter ? 
Il faudrait faire des tests, mais je parierai volontiers que spécifier le type est plus lent que ne pas le faire. Ce dont je suis à peu près certain est que la différence est ultra négligeable.

Côté PHP le typage n'a donc que peu d'importance, contrairement aux SGBD, comme tu as pu le constater dans le lien que je t'ai donné.

Que tu passes à MySQL :
$data 354; ou $data '354';
importe peu, c'est au niveau de mySQL que le typage sera fort, selon le type que tu auras défini pour les champs de la table.

Cordialement,

Kohntark -

cs_danbo · Answer

Merci, je crois bien avoir compris, c'est très clair. Il me reste la question ultime et je ne t'ennuie plus après cela, et en même temps je te réponds sur l'objectif du projet.

Le projet sert à des utilisateurs peu enclins à travailler avec des bases de données, il s'agit de techniciens plutôt fort en mécanique.
Je construis donc un projet simple d'usage, mais il faut que les personnes renseignent à minima la base.
Il se peut que des tables soient à concevoir.
Et là, j'ai tout fait à partir de Flash. L'interface graphique étant très pratique pour en faire un outil pédagogique, elle demande progressivement à l'utilisateur les éléments dont elle a besoin pour se construire. Dès qu'elle les a, elle passe l'ensemble à php qui bâtit la table.
Par exemple, de manière simple, l'interface demande les éléments suivants:
- le nom de la base (il y a une explication au niveau de l'interface)
- le nom de la table
- le nom de chaque champs
- ....

Et là où il y a les pointillés, et c'est ici que je fais en fonction de ta réponse, doit-elle demander le type du champs (integer, float, text ...) ?

Car, l'utilisateur n'ira jamais dans la base pour typer les champs.

Ainsi, y a-t-il necessité de typer MySQL à travers php ? J'ai bien compris que php n'en a pas besoin, mais pour la table, il faut le faire au moment de sa construction, je pense. Est-ce possible à travers php ?

ex : 
$champs = settype("float",ViscositeHuile);

merci

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

kohntark · Answer

J'ai un peu de mal à saisir, pourquoi demander à des "mécaniciens" le nom de la base, de la table, le nom des champs, etc ...
C'est primordial de le comprendre car ton développement PHP en dépendra à coup sur.

mais il faut que les personnes renseignent à minima la base
Quel est le but exactement ?
Des techniciens qui doivent renseigner les opérations effectuées sur un équipement ?
Former ces mêmes techniciens à l'utilisation d'un SGDB ?
... ou que sais je encore.

Tu le vois, je suis franchement paumé sur le but exact.

J'attends ta réponse avant de tenter d'en donner une qui actuellement serait très hasardeuse.


Cordialement,

Kohntark -

cs_danbo · Answer

Bien, je pensais être clair, mais comme dirait l'autre, c'est en se confrontant au monde qu'on voit comment il réagit, ainsi que nous-mêmes!

J'ai trouvé la réponse alors même que je finissais ta réflexion, mais pour ne pas te laisser en reste, je vais clarifier au mieux sur un exemple:

1) on apporte la matière première, des barres d'acier spéciaux calibrés à un régleur spécialisé en forge à froid (on déforme le métal sans le chauffer avec des presses que plusieurs centaines de tonnes).

2) il dispose de matrices d'acier au carbone très dures avec lesquelles il va faire des essais de déformations, essais nécessaires avant toute production en série. Mais on doit analyser les résultats des essais avant d'y aller.
2a) il y a des capteurs en place qui relèvent automatiquement les valeurs de pressions, vitesses, couples, freins, etc....
2b) il y a les valeurs paramétriques du régleur, dont une grande partie ne peut être identifiée par un capteur électronique. Il s'agit d'entrées manuelles faites par lui.

3a) Comme il s'agit d'un essai d'une pièce (pn), le régleur va créer une base de collecte de ses propres relevés, qui s'appellera par exemple (base_pn).
3b) Il va monter la table (table_pn) de la pièce (pn), dans laquelle il va notifier ses propres paramètres (attention on est dans le domaine de l'expérimentation).
3c) Il va donc entrer, par exemple, nombre_d_interventions_sur_poste1, nombre_de_calages_du_zero_pression_huile_circuit1, etc, etc...

En fait, selon la pièce à expérimenter, les paramètres seront tous différents et nouveaux.
Ainsi, pour chaque nouvel essai, on utilisera la même table, ou une nouvelle si nécessaire (amélioration continue).
Pour toute nouvelle forme, on crée un nouvelle base avec les pièces de même famille.
Exemple, il y aura une base Axes, une base, rotules, une base spindels, une base anneaux, etc..
Chaque base contiendra ses propres tables, les produits étant très différents les uns des autres (il n'ont rien à voir entre eux).

C'est pourquoi (collectivement) il a été entendu que les techniciens, pour des raisons de temps et de qualification, n'auront pas à accéder à MySQL (une expérience technique peut prendre de quelques heures à plusieurs jours).

Excel a été rejeté, car le nombre de données collectés sera très important, les matrices auront des tailles imposantes (provenance de plusieurs usines), il faudra faire de multiples liens avec des bases techniques locales et externes, toutes sous MySQL. Donc, c'est le côté pratique de MySQL qui a été invoqué.

Voilà pourquoi je fais ce montage, et le comment de ma question.
Mais, par ta réponse, je laisse php se débrouiller, je peux ainsi monter mes tables de calculs pour analyser les expériences.

Merci à toi,et à tous!

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

kohntark · Answer

Re Danbo,

Quelques réflexions et remarques :

J'ai trouvé la réponse alors même que je finissais ta réflexion, mais pour ne pas te laisser en reste, je vais clarifier 
Ca parait sans doute stupide de le souligner pour des gens comme toi (et moi ) mais j'y tiens !! Répondre aux interrogations des intervenants de ce forum me parait être la moindre des politesses (petit clin d'oeil aux multiples blaireaux qui le peuplent)

Merci pour ta réponse fort bien détaillée.
Il serait sans doute intéressant que tu donnes ici la solution que tu as retenue.

Je me trompes peut être (c'est une constante), mais je pense déceler une certaine incohérence :
le régleur va créer une base de collecte de ses propres relevés, qui s'appellera par exemple (base_pn). 
Il va monter la table (table_pn) de la pièce (pn)
etc ...
Pourquoi créer une base et une table pour cette pièce ?
C'est à mon avis inutile, tu vas complexifier grandement la chose et restreindre la flexibilité globale (recherche dans la Db, stats, etc ...)

Il t'appartient de définir les constantes et de modéliser au mieux, par exemple :
- la machine : elle possède une tripotée de réglages, ces derniers changent dans leurs valeurs, mais pas leur entité :
la valeur d'un pressostat changera, mais pas le capteur lui même, ce qui pourrait être traduit, de façon très basique, par :

Base : machine A
Tables :
pieces : 
  id_type_piece : type de pièce
  autres infos

sensors :
   id_sensor : identifiant unique du capteur
   type_sensor : capteur_pression_machin
   autres infos

actuators :
   id_actuators : identifiant unique
   type_actuator : moteur, verin, ...
   autres infos

params_sensors :
   id_sensor : identifiant lié à la table sensors
   offset : offset appliqué sur la valeur ana du capteur
   multiplier : multiplicateur appliqué à la valeur du capteur
   etc ...

params_actuators :
   id_actuator : identifiant lié à la table actuators
   pressure : pression appliquée au verin id_actuator
etc ...

operators :
   id : id de l'opérateur
   name : nom de l'opérateur
   etc ...


etc ...

Ce n'est ici qu'une trame hyper simpliste pour attirer ton attention sur la nécessité de découper et modéliser efficacement.
En procédant ainsi tu faciliteras grandement la saisie de l'opérateur, et par la même occasion ton développement et l'administration :
(pour rester large et peu précis)
L'opérateur : 
- choisi la machine sur laquelle il opère
- renseigne le type de pièce qu'il produit
- renseigne les paramètres qu'il applique pour les capteurs, les actionneurs, la régul, and co
- par extension, il pourrait renseigner les résultats des tests qualitatifs, mettre des commentaires, les matrices utilisées, les sous traitants impliqués dans la fabrication de ces dernières, etc ...

Selon les choix tu verrouilles au max via des listes de choix (par exemple la pièce X acceptera des matrices M1, M2, M4, M13=> M17 tandis qu'une pièce Y acceptera M1, M7 et M10 uniquement)
La conception de la base est le point névralgique de ton projet, et il passe par une modélisation réfléchie (me répète, je sais ) 

Cordialement,

Kohntark -

cs_danbo · Answer

Kohntark,

Merci pour ta pertinence.
Il est clair que je ne veux surtout pas multiplier les données. tout ce qui sera commun aura le même support.

Je tenais simplement à préciser que les pièces produites sont et peuvent être faites avec des presses de concepts très différents, mais bien entendu, de nombreuses mesures ou méthodes sont communes.

Quand j'exprimais le terme de bases multiples, j'étais déjà dans le résultat. Je concevais simplement reprendre pour une pièce donnée, les éléments justes nécessaires de la base  pour en extraire le jus.
C'est comme si j'extrayais une matrice d'une plus grande avec seulement les paramètres et eux seuls concernant une pièce précise. Peut-être le terme n'était-il pas approprié.
Pour imager, dans un puzzle qui représente un ensemble (la base), je retire la pièce qui m'intéresse (c'est là que j'ai pensé 'base') pour la regarder de plus près.

Merci pour le raisonnement, et bonne nuit !
(oui, je vois qu'il est tard...ou tôt, selon l'humeur !....0h23)

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

neigedhiver · Answer

Salut,

J'aimerais réagir à cet intéressant échange : c'est rare ici des échanges entre personnes civilisées (surtout quand celui qui demande est de ce niveau là), alors franchement, je m'en voudrais à vie de passer à côté d'une telle discussion.

Pour commencer, je voudrais juste contredire un peu Kohntark sur deux points très précis (parce que moi, j'ai le droit de contredire, non ?).
1/ Les fonctions is_float(), in_int() etc ne servent pas à connaître un type, mais à vérifier si une variable est d'un type donné. Oui, je pinaille, mais pour connaitre le type d'une variable, c'est gettype(), et ça n'a rien à voir.

2/ Le fait que PHP soit faiblement typé est un préjudice pour les performances. Pourquoi ? La réponse est assez simple à trouver, intuitivement. Si je n'ai pas les compétences nécessaires en C pour pouvoir expliquer de manière très précise, le fait que les variables soient faiblement typées impose à PHP de faire des traitements supplémentaires en fonction du contexte, pour finalement échouer si vraiment, malgré son laxisme, PHP ne parvient pas à convertir ou interpréter comme l'utilisateur le souhaiterait.
Pour s'en convaincre, il suffit d'effectuer un bench comparant les performances de l'égalité et de l'égalité stricte : et . Le second est plus rapide parce que, justement, PHP n'a pas besoin de comparer les variables en cherchant si en la considérant comme ci ou comme ça ça passe ou pas : s'ils (les types) sont différents, ça passe pas, point barre, donc ça va plus vite et pis c'est tout.

Sinon, danbo , tu sembles maîtriser certains domaines, mais peut-être pas la conception d'une base de données et la modélisation de la réalité. N'étant pas expert moi-même, je me garderai bien de faire la leçon, cependant, j'ai quand même quelques notions d'analyse (des lectures des cours de Merise de mon frère qui me reviennent de temps en temps en tête).

Un des principes de base d'un administrateur de base de données, c'est de ne JAMAIS laisser les utilisateurs finaux créer des bases et des tables. Cela ne doit JAMAIS arriver. En d'autres termes, si ton application a besoin de créer (en fonction de la demande des utilisateurs et de leurs besoins) une base ou un table, alors la base a été mal conçue.
C'est là que mes compétences montrent leurs limites : en l'état actuel, je suis parfaitement incapable de te donner quelque conseil que ce soit plus précis que ceux de Kohntark.
La base de données doit être une représentation de la réalité. Créer une nouvelle base reviendrait à créer un univers, une table une planète.
Toutes les données que tes utilisateurs vont insérer doivent pouvoir être modélisées AVANT mais sûrement pas pendant.
Donc si les utilisateurs peuvent donner des caractéristiques différentes à des objets, toi, en tant que développeur et concepteur de la base de données, tu dois te placer encore un cran au dessus : tu dois pouvoir modéliser les outils qui permettront aux utilisateurs de modéliser des objets du réel.

En gros, Kohntark, j'abonde dans ton sens. Pour faire web 2.0 super tendance : je plussoie.

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

kohntark · Answer

1/ merci pour ce "pinaillement" Neige Tu as raison, il faut être précis. 2/ Ok pour ce qui est des comparaisons, mais je parlais de "mais je parierai volontiers que spécifier le type est plus lent que ne pas le faire" J'entendais : Et là le premier code est plus rapide (1.13546 s) que le second qui spécifie le type (1.26914 s) Bonne journée, Kohntark -

cs_danbo · Answer

Merci à tous deux,

Je vois bien , comme dans les plans d'expériences que la préparation est la fortune de la réussite! Je me doutais bien de la chose, mais vous m'avez mis une sacrée puce à l'oreille, c'est que l'intervention et l'analyse préalable des actions des régleurs sur machine me semble plus qu'indispensable. Je dirais même qu'ils sont à la la base de la base!

On ne fait jamais un travail seul ,et je n'étais pourtant pas dans cette voie, mais une forme d'expertise est utile ici!

Selon ton approche, Kohntark, c'est tout de même 30% d'écart entre les deux valeurs!
Même si en valeurs, il y a peu d'écarts, le pourcentage donne une image très significative de l'utilité du typage.

Ton test m'intéresse, car le serveur qui pédale et manque de puissance, montre des signes de ralentissements si les 40 postes qui lui sont connectés tournent sur lui en même temps , ce qui arrive à des moments où chacun ne le souhaiterait pas.

C'était sous-jacent à ma question du typage.

NeigeDhiver, je tiens donc compte de ta remarque tout aussi pertinente.
J'ai eu la brève et peut-être mauvaise idée de penser que puisque php était loin du typage, qu'il me fallait considérer toutes les valeurs entrantes dans la base comme du 'text', par défaut, par exemple, et retraduire en valeur selon les cas, comme faire de '13.23' un nombre qui soit 13.23.

Je vois qu'il y a risque à ne pas typer. D'ailleurs, sous Flash AS3, le typage est plus que nécessaire, puisqu'il est impossible de programmer sans type. C'est d'ailleurs fait dans un objectif de temps de calcul par Adobe, ce que vous soutenez tous les deux.
Alors, travaillant dans un cycle comme celui-ci:

flash -> php -> MySQL
MySQL -> php -> Flash,

j'ai quand même découvert que mes requêtes duraient un certain temps et que Flash devait être mis en attente avant de poursuivre son code.

L'expérience a du bon ! Je dois reconcevoir les flux d'infos.
je comprends que j'ai plutôt intérêt à typer très fortement.

Le projet comprendra des simulations par la suite, avec prélèvements et injections de données dans la base, à partir de Flash, non plus comme interface de communication, mais comme simulateur, ce qui veut dire que Flash aura de gros calculs à faire (peut-être php s'il est plus rapide, et selon ses fonctions), avec une grosse gestion de données. C'est dire mon intérêt à gagner un maximum de temps et à comprendre l'intérêt du typage, car 30% de gain de temps, ce n'est pas...rien !

merci encore pour cet éclairage.

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

neigedhiver · Answer

Concernant le gain de performances, il se manifeste sur un test qui ne fait QUE ça et sur de nombreuses itérations. Concrètement, dans un script, la différence, perdue au milieu de tout le reste, sera insignifiante.

Concernant la charge, plus tu peux faire faire de calculs par Flash, mieux c'est, puisque les scripts seront exécutés chez le client, allégeant d'autant la charge du serveur. Dans ton cas, j'utiliserais PHP uniquement comme interface avec MySQL, histoire de s'assurer que les données ne sont pas dangereuses et bien celles attendues, laissant le plus possible de calcul à Flash.

Lors d'une requête SELECT sur la base MySQL, le SGBD renvoit des valeurs de types qu'il connaît. L'API étant une extension de PHP, c'est PHP qui va convertir les valeurs de types qu'il ne gère pas en types connus. Un entier restera donc un entier, un float un float, mais on ne récupèrera jamais de booléen, type inconnu chez MySQL (qui utilise des TINYINT à la place (sic)).
Idem pour l'insertion de données, PHP convertira les variables de types non supportés par MySQL.

D'une manière générale, même si PHP est faiblement typé, je pense qu'il est toujours préférable de savoir précisément le type de chaque variable que l'on utilise et autant que possible utiliser des comparaisons d'égalité strictes !et 

Pour finir, si tes requêtes sont vraiment longues, il n'est pas impossible que cela vienne du fait de la conception de ta base ;)

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

cs_danbo · Answer

Merci à vous deux pour l'additif important.
Je tiens compte des avis.

Je viens par ailleurs, et je pense me tirer d'affaire ensuite, de créer un post de ce sujet:

'Synchronisation Flash - php'..

qui est lié à ce travail, où j'ai un souci de synchro entre FLash et php.
Si vous avez l'expérience en ce domaine, je serai heureux d'avoir vos avis.

Ceci dit, je n'aime pas le travail mâché, mais si vous avez des pistes, j'aime bien les triturer dans la mesure où mes neurones sont demandeurs.

Cordialement

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

kohntark · Answer

Selon ton approche, Kohntark, c'est tout de même 30% d'écart entre les deux valeurs! 
Oui, c'est 30% plus rapide lorsque l'on ne type pas les variables
=>
$machin 'truc'; est plus rapide que $machin (string) 'truc';

Même si en valeurs, il y a peu d'écarts, le pourcentage donne une image très significative de l'utilité du typage.

 c'est l'inverse, ça fait perdre du temps que de les typer, et ça peut se comprendre puisqu'une instruction est ajoutée (pour en être certain il faudrait farfouiller dans le code du moteur, mais là ...)
N'oublies pas une chose : il s'agit de 5 millions d'itérations !!
Autant dire que typer ou ne pas typer les variables dans un script normal ne change absolument rien en terme de temps d'exécution.
Il n'y a vraisemblablement aucune utilité (dans ce cas) à typer tes variables côté PHP, en revanche c'est primordial côté MySql et Flash.

Les lenteurs que tu rencontres peuvent provenir de multiples choses, de la construction de la base, comme l'a souligné Neige, mais aussi de celle de ton code PHP, de tes requêtes, etc ... Sauf à voir le code il n'est pas possible de le déterminer.

Cordialement,


Kohntark -

cs_danbo · Answer

Merci à vous pour les apports constructifs.
Bonne continuation.
Peut-être à un autre post (même si je ne viens pas souvent)!

Ailleurs n'est point ici. D'ailleurs ici ou ailleurs, c'est quand même  pas là!

Typage des variables MySQL via PHP

18 réponses

Votre réponse

Discussions similaires