Oui.

Maintenant que j'ai crée un index sur deux ID crées dans chacune de ces deux tables, attachées l'une a l'autre désormais, comment puis-je faire ma soustraction ?

Pourquoi tu pales d'index, ca n'a rien à voir avec ça les index.

Honnêtement, je pense que tu te complexifies la tâche pour rien. Ca n'a pas d'intérêt de vouloir stocker partout les résultats d'opérations entre tables; voir meme au sein d'un seule table comme tu l'as fait.

Ok c'est beau, c'est magique d'avoir tout qui est à disposition en base à tout moment, mais en vrai ca n'apporte rien (en tout cas je trouve), au début je partais du principe que tu avais une bonne raison de le faire, mais suite à nos échanges, je pense plutôt que c'est une envie comme ca, une lubie qui n'a pas de réel intérêt techniquement parlant, et que tu peux parfaitement bien t'en passer justement en faisant tes calculs comme tout le monde. Et que donc tu veux faire ça comme ca parce que tu ne maitrises pas vraiment ce que tu fais (la preuve que tu ne maitrises pas vu que tu ne savais pas vraiment gérer les FK).

Attention, c'est pas une insulte ou une critique, on a tous commencer par la, y'a pas de mal.

En soit tu n'as pas besoin que ta valeur soit présente à tout moment dans tes tables, tu as juste besoin de pouvoir y accéder quand tu vas faire un SELECT. Et magie, tu peux tout simplement faite ton addition ou ta soustraction au moment du SELECT.

Ca sert à ca les SELECT tu sais, un SELECT c'est pas juste fait pour sortir un SELECT * FROM myTable, ca te permet aussi de faire des calculs dedans, de faire des jointures en te servant de FK, etc.

SELECT tableA.valeurA - tableB.valeurB
FROM tableA a
INNER JOIN tableB b
WHERE a.id = b.idA

Et hop, ta soustraction entre tes 2 tables est faite.

Quel est le vrai intérêt de stocker ta valeur en base ? En soit il pourrait y en avoir, genre pour des raisons de perfs par exemple, et encore, ca serait potentiellement + performant que dans certains cas précis, ce qui n'est a priori pas ton cas. 

Stocker une valeur dans une table qui peut se calculer à partir de 2 autres, ca va à l'encontre des principes de bases d'une base de données relationnelles, qui dit que le but c'est d'éviter autant que possible d'avoir de la redondance d'information, de la duplication de données. Or c'est exactement ce que tu fais, tu crées un champ, qui prend de la place mémoire, qui se calcule avec un simple "+" ou un simple "-". C'est surcharger ta table avec des colonnes inutiles, c'est prendre de la place mémoire en base pour rien.

Je te déconseille fortement de continuer sur cette voie, sinon tu vas jamais t'en sortir. Si tu bosses souvent avec une bdd, tu verras très très souvent des calculs entre des colonnes (le classique "prix_achat"x"quantité" par exemple, ou "prix_vente"x"quantité"), et est-ce qu'il faut stocker ces résultats de calculs systématiquement dans d'autres colonnes ? Non.

A ta place, je laisserais ca de coté, je virerais toutes ces colonnes "auto-calculées" de tes tables, et je me contenterais de faire les calculs dans les SELECT.

-
Edité par Tiffado 28 mars 2023 à 16:31:36

Oui,

-
Edité par (...) 9 juin 2023 à 12:14:35

Et pourquoi ca?

Parce que

-
Edité par (...) 9 juin 2023 à 12:14:42

Le but de ton projet, c'est explicitement de "stocker ces valeurs pré-calculées en base" ? Ou c'est juste qu'avoir accès à ces valeurs quand on en a besoin ?

Pour moi tu as 2 cas possibles :

1/ Tu as un cours dédié aux données GENERATED, et ton prof te demande de faire ça. 

=> J'ai envie de dire, demande à ton prof, revois ton cours, demande à tes potes de classe

2/ Tu as juste besoin d'avoir accès à ces additions/soustractions quand tu en as besoin.

=> Tu peux te passer de les stocker.

Et vu que tu as explorer le concept des TRIGGER, ca me fait largement partir sur l'option 2.

Honnêtement, je comprends bien que tu demandes une chose précise, mais le but d'un forum d'entraide, c'est pas forcément de répondre bêtement aux questions, mais aussi de remettre sur le droit chemin si nécessaire.

Je suis adepte de l'idée du "Dis moi pourquoi tu en as besoin, je t'expliquerai comment t'en passer". Et pour moi on est pile dans ce cas la.

Si tu as une contrainte technique qui fait que tu dois ABSOLUMENT stocker ta valeur, alors on verra pour trouver une solution à ton soucis, mais si tu n'as pas ce genre de contraire, alors il faut apprendre les bonnes pratiques. Et honnêtement, de ce que tu dis depuis le début, je vois pas en quoi c'est obligatoire, et c'est pas un "Parce que" qui va me convaincre.

PS : Je te cache pas que je dis aussi ça parce que, autant calculer une colonne GENERATED depuis d'autres colonnes de la même table, c'est facile. Autant une colonne qui se calcule depuis plusieurs tables, c'est la merde, et je suis même pas sur que ca puisse se faire avec une colonne GENERATED. Et dans ce cas la, l'idée serait de partir sur une solution plus simple, comme j'essaie de t'expliquer.

-
Edité par Tiffado 28 mars 2023 à 17:14:19

Dans ce cas,

-
Edité par (...) 9 juin 2023 à 12:14:52

Désolé mais c'est contre mes principes pro d'aider quelqu'un à faire quelque chose que j'estime être opposé aux bonnes pratiques (sauf pour de bonnes raisons).

Si tu n'arrives pas à me prouver que c'est nécessaire pour toi de stocker ces valeurs, c'est que c'est pas nécessaire. Et si c'est pas nécessaire, alors voir mes messages + haut.

Pour info, l'idée de rapatrier tes valeurs d'une table vers la 1ere, on va analyser ca :

1/ Si tu as une relation 1:1 entre tes 2 tables, alors pourquoi avoir 2 tables ?

2/ Si tu as une relation de type 1:n entre tes 2 tables : alors tu rapatries quelle valeur ? faut en choisir une au pif sur les n ?

3/ Si tu as une relation de type n:1 entre tes2 tables : alors tu devras rapatrier ta valeur n fois => tu perds le concept de modèle relationnel.

4/ Si tu as une relation de type 0:? ou ?:0 : alors c'est voué à l'échec, automatiser un calcul qui peut ne pas exister, c'est pas la peine, c'est bug sur bug.

-
Edité par Tiffado 28 mars 2023 à 17:34:26

Salut,

-
Edité par (...) 9 juin 2023 à 12:14:59

Tables employés et tâches donc. (je t'avoue que le nom "opérateurs" peut avoir plusieurs sens à mes yeux, employés c'est + clair).

Du moins c'est bien ca ? Opérateur = employé ? Si oui, il faudra sans doute revoir tes noms de colonnes par ci par la. Si ton identite_employe d'une table correspond à ton identite_operateur de l'autre table, alors c'est pas clair. D'autant + que le type est différent (VARCHAR 55 et 100). Honnêtement ca serait pas du luxe de revoir ton modèle de données pour clarifier des trucs.

Donc dans la logique des choses, tu peux avoir plusieurs tâches par employé, on est donc dans une relation 1:n.

Si tu es dans une relation 1:n, ca veut dire quoi ton calcul "operateurs.operateurs_charge = operateurs.disponibilite - taches.charge_initiale" ?

Pour moi ca veut rien dire, vu que tu as plusieurs tâches par operateur. Donc la logique serait plutot de faire un truc comme :

operateurs.operateurs_charge = operateurs.disponibilite - sum(taches.charge_initiale)

Ce qui rend ton calcul encore plus complexe. Complexe, mais je rapelle qu'il se ferait très bien dans un SELECT.

Donc vu qu'on est bien dans le cadre d'un projet avec un prof, peux-tu, stp, nous donner ton énoncé ? Histoire qu'on évite d'aller à la pêche aux infos et qu'on ait toutes les infos d'un coup.

-
Edité par Tiffado 29 mars 2023 à 11:10:29

Oui,

-
Edité par (...) 9 juin 2023 à 12:15:05

Donc vu qu'on est bien dans le cadre d'un projet avec un prof, peux-tu, stp, nous donner ton énoncé ? Histoire qu'on évite d'aller à la pêche aux infos et qu'on ait toutes les infos d'un coup.

Je

-
Edité par (...) 9 juin 2023 à 12:17:20

Non, tu as expliqué avec tes mots ce que tu penses avoir compris de ce que le prof a dit. Y'a un monde entre ca et "les explications du prof"

2

-
Edité par (...) 9 juin 2023 à 12:17:48

Cette requete ne fonctionne pas. ca sera plutot apr un truc comme ca :

UPDATE operateur
    SET charge = dispo - (SELECT SUM(tempsTotal) FROM tache WHERE id_ope = 1)
    WHERE id_ope = 1 ;

A caller dans un TRIGGER after update/insert, en changeant le 1 par l'id de l'opérateur que tu motifies/ajoutes

C'est

-
Edité par (...) 9 juin 2023 à 12:17:53

il y a la fonction TIMEDIFF si tu veux du time en résultat

Oui,

-
Edité par (...) 9 juin 2023 à 12:17:59

On doit jouer aux devinettes ? tes 2 "temps" ont le même format ? un exemple, ce que tu obtiens et ce que tu veux ?

Time est limité à +/-839heures-1 secondes, donc un peu moins de 35 jours; sinon voir à utiliser TIMESTAMPDIFF
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_timediff 

Cela 

-
Edité par (...) 9 juin 2023 à 12:18:05

Désolé mais j'arrête d'essayer d'aider ici.

J'en ai marre de devoir aller a la pêche aux infos. Comment veux tu qu'on te dise ce qui va pas si tu nous montres pas ta requête ou les valeur que tu as.

si les 2 ont la même valeur, le résultat logique de leur différence est bien 0. Valeur et type ce n'est pas la même chose. INT, VARCHAR, TIME, DATE sont des types et 212, 'toto', '13:24:36.52', '2023-03-30 15:36:23.65'  des valeurs de ces types (sous forme de chaine pour TIME et DATE)

si c'est NULL, la doc indique que c'est parce qu'au moins l'un des 2 est NULL (NULL n'est pas 0).

La requête 

-
Edité par (...) 9 juin 2023 à 12:18:15

Supprime les guillemets simples autour des noms de colonne, ça devrait aller bien mieux je pense.

Ton idée ne changera rien à la problématique à mon avis, si la requête est mauvaise.

(...) a écrit:

...

1 - Créer une autre colonne charge_initiale dans la table operateurs qui importe automatiquement les VALEURS de la colonne charge_initiale de la table taches.

2 - Que la colonne operateurs_charge soit le résultat de cette soustraction entre les colonnes disponibilite et charge_initiale, de la MÊME COLONNE.

...

C'est non, tu as plusieurs taches par opérateur, donc a minima elle devrait stocker la somme des charges de ces taches. Mais si tu sais faire ca, autant directement faire la total et mettre la soustraction avec.

La requête 

-
Edité par (...) 9 juin 2023 à 12:18:22

SELECT SEC_TO_TIME(TIME_TO_SEC(time_colonne_1) - TIME_TO_SEC(time_colonne_2)) AS difference
FROM table;

Je persiste toujours que pour moi tu n'as aucune obligation de stocker cette valeur en base, mais bon.

-
Edité par Tiffado 31 mars 2023 à 14:44:26

-
Edité par (...) 9 juin 2023 à 12:18:27

LIS LA DOC:

TIMESTAMPDIFF renvoie un nombre entier de l'unité de temps demandé, pourquoi il renverrai un TIME.

Côté PHP rien n'empêche d'utiliser plusieurs tableaux dans une boucle pour faire de l'affichage.