SQL: Encodage de Varchar

QUESTION 1 : RESOLUE
Imaginons la colonne A et la colonne B
Est-il possible de créer la colonne B en fonction de la colonne A? et que B=2xA (par exemple)
Et que si j'update une valeur de la colonne A, la colonne B se mette à jour sans requête?
(un peu comme peu le faire Excel finalement)

QUESTION 2
j'update ma question!
c'est à propos de l'encodage des infos.
j'ai mis mes varchar en UTF8
et j'ai mis mon fichier php en UTF8 sans BOM.
je comprends pas pourquoi ça afficher pas mes accents et caractères particuliers...
��������
help!

@Wiliwilliam_ Nop et excel non plus au passage.
Oui Excel le fait mais parce qu'il y a une formule derrière ^^. Mais, pour en revenir au sujet, les triggers permettent d'automatiser ça de manière totalement invisible pour l'utilisateur.

Si besoin je devrais pouvoir t'aider, à condition de développé un peu le besoin .

des opérations à la con

une colonne A dont les valeurs varient de 1 à 99 et une autre B dont les valeurs varient de 1.00 à 2.00
il faut stocker AxB dans une troisieme colonne C, à chaque fois qu'une valeur que A ou B change (pour une ligne simplement)

mais la question du coup c'est: est ce que c'est pas moins couteux de faire ça dans une requête? ou le trigger est vraiment très léger?

NB: j'ai besoin des 3 colonnes! il me les faut dans la BDD

@Wiliwilliam_
Alors 'colonne' n'existe pas, on parle de 'champ' dans une base de donnée. (oui je pinaille mais c'est plus facile pour se comprendre ensuite ^^)
Ensuite un trigger ralenti forcément car c'est une seconde requête qui s'exécute mais on parle de temps machine de quelques dixième de seconde (sauf cas exceptionnel)

La question que je me pose: Pourquoi tu as absolument besoin des 3 valeurs dans ta table?

parce que je récupère la première valeur via une API de manière chronique, que la seconde varie en fonction d'action sur un site (complètement aléatoire) et que je fais un affichage avec les trois valeurs.
Non mais donc en fait je me prends la tête pour rien, j'intégrerais la multiplication dans la requête API.

Merci pour les infos et les précisions de vocabulaire

@Wiliwilliam_ : Ne tiens pas compte de ses précisions de vocabulaire : elles sont fausses.

On utilise bien le terme "colonne".

hahaaaaa?





en 3 round! les coups sur la famille et le physique sont interdits!

@Wiliwilliam_ Pas de soucis cela peut sembler pénible mais utilisé les bon termes permettent aussi des recherches plus efficace sur le net .

Cela fait partie des "best pratice" en DB: ne stocker que l'information que tu ne peux pas calculer autrement.
De même je te conseil fortement de faire des procédures stockée, comme ça tu ne modifies qu'a un seul endroit en cas de modif et accessoirement histoire d'avoir la main sur ce qui rentre et sors de la DB.

Et tu n'es pas obliger de le calculer dans l'API, fais le au moment de la requête:



Citation :

en SQL? t'as fumer quoi?
On utilise le mot champ qui est une traduction de l'anglais "Fields".

On parle de champs dans la table mais de colonne dans les résultats.

oui oui au moment de la requête, je me suis mal exprimé! (un autre koreusien bien inspiré m'avait conseillé de faire faire un max de boulot par la BDD :-D)

@Wiliwilliam_ C'est pas forcément faux, ça dépends de quand cette info date, a une période on stockai tout en DB, y compris les images:p.
De plus en plus c'est l'esprit POO qui prend le dessus et donc chaque objet à une fonction définie. Dans cet optique la DB ne sert qu'à stocker du data.

Mais quitte a faire quelque chose de nouveau autant le faire au standard actuel .

c'est un jeu pour les koreusiens, je vais pas me prendre trop le chou

Citation :

J'ai fumé la doc MySQL.

https://dev.mysql.com/doc/refman/5.7/en/create-table.html
https://dev.mysql.com/doc/refman/5.7/en/alter-table.html

On utilise bien le mot colonne qui est une traduction de l'anglais "column".

@-Flo- J'ai corriger plus haut car je pense avoir compris l'erreur.

Champs c'est quand on est dans la DB et Column c'est dans le tableau de résultat de requête ou alors c'est juste Microsoft qui utilise cette différenciation ou Oracle qui tente d'imposer un nouveau standard en mettant colonne partout .

C'est quand même zarb parce que plein de cours et de site utilise le terme "champ" quand il parle de la DB (pas du résultat de requête qui lui est bien un tableau ligne/col )

@Arsenick : Pas vraiment. Les colonnes servent à définir la structure d'une table. Les insertions qui sont faites dans cette table créent des lignes. Un champ est l'intersection d'une ligne et d'une colonne.

@-Flo- J'ai toujours vu partout le terme champ pour définir une table et les intersection Col/Ligne c'est une cellule.
Franchement ça me perturbe.

Et désolé, je me rend compte que ma réponse était quelque peu agressive. :oops:

@Wiliwilliam_

Je ne connais pas ton besoin exact, mais il n'est inutile de dupliquer une colonne si la valeur de la 2eme colonne dépend de la première.

Le mieux c'est de faire le select qui va bien

SELECT A, 2*A as B FROM matable

en sql on stock pas de valeur calculer/redondante, si tu peu trouvé B grâce a A alors tu le stock pas , tu le calcule au moment de ta requête ou post-requête

J'comprends pas ce que tu veux faire exactement, mais si tu crées une vue b que tu mets à jours via la table a
Du style



(J'ai pas test le code, mais ça devrait y ressembler) Du coup,à chaque update de a, la vue b sera update sans commande supplémentaire.

Nan mais ce que koreus a écrit correspond très bien.
Bêtement j'ai voulu trop stocker de trucs pour éviter d'avoir à effectuer des calculs en php ensuite , mais j'ai oublié que rien ne m'empêchait de faire un calcul quand je récupérerai les résultats

[Compte supprimé]