Reprise du message précédent :

Il faut rester sur r/france si tu préfères leur façon de faire

go Owntracks?  
https://owntracks.org/
 
tu peux même y importer ta timeline Google.

Tel un papillon face à une lampe halogène, tu n'a pas su résister et tu as succombé à la tentation

r/france le problème c'est que c'est un peu trop centriste mais bon

https://youtu.be/7xTGNNLPyMI?si=UM1 [...] BkM&t=9037
petite pépite intéressante sur le lien entre longueur de la réponse et la correction du résultat.
Je suppose qu'on peut leur faire produire une réponse assez longue, la mettre dans le contexte, et lui faire sortir un résumé.

edit: hum c'est ce que fait openAI.

 
Non, là c'est pas la modération d'un subreddit, c'est le niveau supérieur, la modération au niveau site qui m'a banni 7 jours. Et ça, c'est uniquement parce que Musk les menace.

Je connaissais pas, merci. Bien cool l'import G Timeline  

Le nas arrive au bout de sa vie là, vous avez quoi dans vos escarcelles en idée / prix pas trop cher, il me faut du 10 baies et de quoi stocker 80To avec 2 disques en spare.

mais je pense faire petit à petit pour l'achat des disques car là ils sont chers en ce moment et ptet prendre un peu de tout.

Je me dis que je devrais rester chez Syno avec un 12Baies mais 2000 boules ça fait mal

Faire le NAS moi même c'est chaud quand même mais au moins j'aurai la main sur la moindre pièce mais il faudra que je gere correctement le RAID avec tous les disques, mais même avec de la bonne volonotée, il y en a pour 800 balles

Bah tu paieras toujours plus cher un Syno qu'un custom.

Y'a un topic HFR si tu veux du conseils, mais le RAID me semble pas bien compliqué. Et au pire ça se fait via OMV, unRaid ou autre.

Edit: Du 10 baies chez Syno c'est genre le DS2422+ et c'est 2300 boules.

80 To ca tient dans un 6 baies en fait  

Qui a besoin de 80To pour son usage perso ?

oui, je me tate à passer à du unraid, à l'époque j'avais pris une licence, mais unraid c'était à chier, maintenant c'est mieux et plus carré, donc je vais regarder  ça de plus près.

c'est pas la question en fait

Dites les fibreux j'ai une question code/bdd, j'aimerai bien un avis.
 
J'ai une app (php/mysql) du genre calendrier avec des rendez-vous. Et historiquement un rdv est associé à un client unique.  
Donc j'ai une table rdv, avec un client_id directement dedans (pas de table de liaison rdv_client(rdvi_id,client_id). Avec au passage plein de données associées au contenu du rendez-vous et spécifiques au client.
 
Je planche sur une évolution pour permettre la création de rendez-vous "multi clients", genre pour faire un parallèle ça serait comme un psy qui aurait des rendez-vous avec 1 patient, mais aussi parfois des sessions de groupe.
Je suis un peu niqué parce que toute l'app repose sur le fait qu'il n'y a qu'un client par rendez-vous, par exemple j'ai un système de rappel du rendez-vous qui va stocker le fait qu'on a bien envoyé le rappel, à quelle date, DANS cette table rdv. J'ai toute une pelleté de champs spécifiques pour le contenu du rendez-vous, donc spécifique d'un client.
 
Si vous avez des idées comme ça sur une manière pas trop dégueu de m'en sortir pour permettre à un rendez-vous d'être associé à plusieurs clients, je suis preneur.

pas trop le choix que d'ajouter une table intermediaire <client , rdv>  
et ce sera dans cette table que tu stocker le rappel
 
tu pourras eventuellement une vue qui te preacalcul des choses au niveau du rdv , genre nombre de participants / nombre de participants ayant été rappelés

 
à part extraire une table de relation rdv_client, tu veux dire?

et si tu commences a vouloir mettre les id clients en json / csv dans une colonne de ta table rdv, je viens te taper

ouais j'avais imaginé faire un truc du genre mettre un rdv_id à -1 pour les rdv à plusieurs pour les séparer et faire un truc en parallèle spécifique pour ces rendez-vous, mais j'imagine que flo viendrait me démembrer également
 
Je suis bon pour 6 mois de remise à plat (ouais je suis lent)

Sinon si tu veux faire crado original tu modifies ta table utilisateur en ajoutant un flag qui indique que c'est en fait un groupe, et tu ajoutes une table groupe et une table qui fait le lien. Comme ça tes rdv sont toujours sur un seul "utilisateur"

 
J'aime bien

Et comment tu fais pour les rappels, les données relatives aux personnes, etc?
Si tu dois envoyer un SMS ou un l'ail de rappel a un groupe, tu demandes aux clients de s'inscrire sur le WhatsApp de leur thérapie de groupe?

Il te faut un truc propre : un table avec tes patients, une autre avec tes rdvs et une table de jointure.

ben va sur /r/merdeinfrance

Ah oui ça créé tout un nouveau bordel à gérer, c'est clair. Faut stocker les rappels (et d'autres trucs) ailleurs.
J'ai mis un smiley parce que je me doute que c'est bancal.
 
En fait l'idée que j'aime bien c'est que ça ne pète quasiment pas l'existant. J'ai toujours du mal à tout péter parce que les répercussions vont souvent 3 fois plus loin que ce qu'on s'imagine au départ.

Ahah, trop drôle.

Ouais enfin....

Tu as une table rdv avec les données du rdv et celles du patient relatives au rdv.

Il faut juste la scinder en deux :

- les donnees relatives au rdv (indépendantes du/des patients, genre horaire) dans une table,
- le reste dans une autre
- une jointure n-n entre les deux,

C'est pas délirant comme modification.

En autre approche :
créer X rendez-vous à la même date/heure, un par client et trouver un moyen de les regrouper, soit d'un point de vue affichage (genre si plusieurs rdv ont la même heure de début et de fin on considère que c'est un groupe dans la vue calendrier) soit de manière plus formelle via une table dédiée.

Pourquoi être agressif avec depart alors qu'il est tout choupi.
 

Y a Kyan Khojandi en interview par David : https://youtu.be/hdLpFZVjvgM

Photo + vidéo 4k/8k si tu sauves tes rush et les montages.
 
Également si tu écrit beaucoup beaucoup de code, un dev golang qui se respecte par exemple, doit avoir minimum 4-5 To de if err != nil { return err }

Mais oui putain !!!!

 
Déjà vu, donne autre chose.

 
Pourquoi es-tu agressif ?  

 
Mwouai...  
 
Je me rends compte que plus l'appareil est performant et récent (plus de pixels) et moins j'aime ma tronche. Bon OK je vieillis, mais quand même.    J'aime bien les lifting naturels des appareils low tech.  

Des rush 4k/8k ça pèse quand même très lourd.
 
Mon appareil photo fait du 47mpix c'est largement suffisant

 
Parce que c'est complètement con.
 
Les regrouper ça consiste à créer un identifiant de RDV unique. à partir de là, dupliquer les infos du RDV autant de fois qu'il y a de participants introduit une redondance qu'il faudra gérer. Et c'est chiant.  
Si tu crées cet identifiant alors tu y rattaches toutes les infos directement relatives au RDV, c'est tout.
 
La seule raison de vouloir faire ça, ça serait une problématique de cardinalité qui fait que la jointure pose un problème  de perfs majeur quand tu lis pas l'un des bouts de ta relation.
 
 

Ben en fait dans cette table rdv, je dirai que les trois quarts des donnée sont spécifiques d'un client (les données de ce client générées lors de ce rendez-vous). Finalement ce qui reste "mutualisable" c'est ce qui a trait à la date/durée/lieu et 2,3 autres trucs.
 
Mais je suis d'accord que pour par exemple déplacer un rdv, ça risque d'être chiant (faut le faire pour tous les rdv de cette même date/heure) c'est un peu du bricolage.
 
Qu'on soit clair, je sais que la solution d'une table d'association n-n est LA manière propre de le faire, j'essaie juste d'explorer le niveau de déguelassité ou non des autres approches, sachant que la quantité de boulot derrière le passage à une table d'asso n-n est colossal : 1 seul dev, toute l'app tourne autour de cet agenda, beaucoup de répercussions dans des trucs franchement pénibles à gérer... ceux qui ont déjà travaillé sur des agenda et leurs paquets de contraintes associées (vive les manipulations de dates) savent.

 
C'est Samuel Altman qui a dit : The best time to normalize your data was 20 years ago. The second best time is now.

Alors je doute qu'il soit si colossal que ça.

Parce que toute la partie algo reste la même. C'est juste l'endroit où tu récupères les données en entrée, et celui où tu les écris en sortie qui change.

Ou alors c'est qu'il est temps de penser à ajouter des abstractions dans ton code

Amen
 
C'était normalisé pour une liaison 1-1

Rien que l'affichage de mon agenda : aujourd'hui c'est (principalement) une boucle qui pour la journée X va chercher dans ma table rdv avec un inner join sur ma table client pour afficher par exemple le nom du client pour le créneau concerné.
Si je rajoute une table entre les 2, et que j'ai potentiellement 1 rdv avec 2 clients, je ne peux pas garder l'inner join, car sinon je vais me retrouver avec 2 lignes pour 1 rdv, donc mon affichage va vouloir afficher 2 rdv pour 2 personnes différentes sur le même créneau.
Donc non ça n'est pas si trivial que ça.

....
 
non mais évidemment que l'affichage va devoir s'adapter.
 
Aujourd'hui ton machin n'a qu'un niveau de boucle (le RDV)
Maintenant il en faut 2, à moins que tu n'arrives à faire entrer toutes les infos de X patients dans une IHM prévue pour enm afficher un seul, ce qui sera immanquablement dégueulasse et illisible sans refonte ;majeure.
 
Donc dans tous les cas tu auras une refonte à faire : autant faire celle qui va dans la bonne direction.