Reprise du message précédent :

c'était moi, pour Oroville.

C’était nray qui avait beaucoup posté sur Oroville (situation assez différente: le barrage a été extrêmement endommagé au niveau du déversoir principal — et de l’évacuateur de crues / déversoir auxiliaire — mais n’a pas lâché, et les communautés en aval avaient été évacuées au cas où).
 
Grady a aussi une vidéo sur Oroville (enfin plusieurs mais une sur le rapport d’ingénierie), https://youtu.be/jxNM4DGBRMU
 
edit:

Ok,
Mais je garantis pas de propositions en 1h après

J'ai du retard sur mon planning de footing, faut que j'y aille là  

Avec Dion modo ça ne se passerait pas comme ça  

 
 
click droit / pieds de page.

Alors à la maison j'ai un peu de tout, je conseille fortement une nvidia shield TV. mais si tu as d'autres TV dans la maison, fire stick TV, c'est suffisant.
 
Dans le salon j'ai la 75 pouces 4K avec la shield TV (dont l'IA pour l'upscaling qui marche très bien)
Pour les autres TV en 1080p (pas besoin de plus) c'est du mi box S, mi stick ou fire stick tv

Ben tu filtres quoi sur le topic ?

jovalise

Je vais chercher le pain.

On est gromanche je ne l'avais point vu

En fait, le sol chutte.
C'est ce qui donne g.
g c'est l'égale en amour à 1.
La pression exercé au sol est la même que celle exercé sur le corp.

les plans sont ici : https://drive.google.com/drive/fold [...] sp=sharing
 
le modèle complet est ici : https://a360.co/3af2mGi

L'eau est le lit de l'amour.
Elle nous a chassé ; Je ne sais pourquoi.
 
Que la paix soit avec vous.
Amen.

Masklinn modo, vite !

Je me demande : il y a un post concernant les question programmation, genre "concepts", sans forcément être un langage spécifique, mais plutôt des interrogations sur des best practices, des choses comme ça... ou alors c'est ici ?
 
Parce que j'ai une question, et la dernière fois que j'en ai posé une du genre ici, ça a été le fiasco total...

Sous-cat “divers”.

 
Ta demande devait être trop complexe.
 
Mais si tu cherches une solution complètement overkill à un problème simple ou si tu veux refaire ta maison, t'es au bon endroit.

quelques jours.
A+,

En espérant qu'il reprenne son traitement d'ici là.
J'ai un voisin qui est pas mal comme lui dès qu'il prend plus ses médocs, alors je suis relativement tolérant avec ce genre de problématique, mais la il s'est lâché.
A+,

Vu ses derniers posts sur discu avant de se faire bannir ça semble peu probable

Tu sais, un simple médoc, ça peut faire des miracles.
Suffit que mon voisin le prenne 2j, et il est quasi normal.
Sinon, il te parle de ses romans et autres pièces d'or.
 
A+,

Ma question du jour c'est :

J'ai une application Web (stack lamp à l'ancienne).

J'ai des comptes clients, avec email / mot de passe (création de compte via le site). Quand un client a créé un compte, il aboutit dans une table client avec des dizaines de champs car ensuite il y a plein d'infos à stocker (tout un profil, des paramètres...)

Je veux maintenant pouvoir créer des prospects, en gros des gens qui laissent juste leur mail, ou éventuellement un nom/prénom en plus et pour lequel je veux aussi pouvoir traquer quelques actions (genre des abonnements newsletter, téléchargements d'un guide offert...).

Bien entendu le but sera de convertir les prospects en client.

Bien entendu ( ) les clients vont pouvoir faire des actions communes avec les prospects (genre téléchargement du guide offert, recevoir certains mails, s'en désabonner... ).

Ça serait quoi le best practice en terme de bdd pour stocker tout ça ?

J'aime pas bien l'idée de mettre mes prospects dans la table des clients... mais faire 2 tables génère un bordel pas possible pour certaines actions (genre tu veux te désabonner de la newsletter, il faut checker dans quelle table la personne est, avoir 2 procédures différentes...)

Faire une table commune genre "personne" avec les infos communes (email, abonnement...) puis une table prospect + une table client pour les spécificités ça me semble aussi overkill.

Bref je suis preneur d'idées.

Qu'est-ce qui est overkill dans la dernière solution ? C'est la migration qui est relou ?

De manière générale, des données normalisées qui collent à la réalité c'est rarement une mauvaise idée.

Pareil, la dernière solution me parait correcte. En tous cas plus que de mettre tes prospects dans la table client et donc de devoir mettre pleins de champs en optionnels dans ta table client (vu qu'à priori tu n'auras pas ces infos pour les prospects)
 
Sur la majorité des frameworks web modernes pour limiter les problèmes dont tu parles dans ta 2ème solution (une table par type), tu as des choses pour aider à gérer ça avec de l'héritage de modèle, même si faut bien lire les docs parce que ça peut réserver des surprises.

Du coup perso je gèrerais ça comme n'importe quelle dette technique : on évalue le coût à de maintenir la solution crado (effectivement la solution à deux table paraît moins casse-gueule vue de loin), et on estime si c'est pertinent de payer la dette ou pas. On implique les décideurs. Si on ne la paye pas, chaque fois qu'on perd du temps à cause du schéma pourri avec deux tables on ne manque pas de le signaler pour que les décideurs soient au courant.

Si tu veux pas t’emmerder tu renommes ta table en user et tu ajoutes un booléen isProspect et fin de l’histoire.  
 
Le filtre est rapide pour différencier les deux, et le nombre de colonne on s’en branle un peu. Surtout si à la fin c’est pour transformer les prospects en client.

rajoute ces prospects dans la même table, une colonne supplémentaire is_prospect default false.
 
Comme ca tes anciennes features n'ont a être touchées que si tu veux intégrer les prospects dedans (newsletter etc), et les features pour les prospects uniquement n'impactent pas les vrai users (relance ou je ne sais quoi).
 
ca me paraît assez simple pour migrer et encore moins overkill, le risque à faire trop compliqué c'est YAGNI classique à te faire chier a tout normaliser pour rien

on se comprends

Perso si c'est une vieille appli moche qui doit mourir, booleen isProspect et roule.

Mais si c'est un truc censé être pérenne/maintenu dans la durée, on fait propre.

il a parlé de LAMP

Ca peut rester "pérenne" suivant les boites

J'insistais plus sur le mourir  

+1000

C'est sa solution 1. C'est moche.

Ah, ça fait débat, cool

Ouais "moche" mais simple et efficace ? (1)

Normalisé, des objets, des surcharges et des usines à gaz (dernière solution) ?

J'avoue être un peu revenu du "beau", parce que j'ai parfois constaté que justement c'était dans ce genre de solution que je finissais par passer des heures à debugger ou mettre en place des méthodes ultra compliquées... Parfaites pour la réutilisation... sauf qu'elles ne servent qu'à un seul endroit. Ou à l'inverse un précepte de base qui ne l'est plus, genre la "personne" avec comme clé son mail... le jour où tu veux des prospects dont tu n'as que le numéro de téléphone ça part en cacahuète...

j'ajouterai aussi un champ dans la table user . Ou même je n'en ajouterai pas : un prospect est un user qui n'a pas tout rempli. Un user a fait une commande et a donc remplit tout ces champs
 
Et sinon, on va probablement visiter une maison qui était en location. Est ce qu'il y a des points de vigilance a avoir sur des économies faite par un bailleurs pour optimiser le rendement ?  

Non mais voilà, quitte à faire de la merde, une deuxième table c'est moche aussi mais au moins tu assumes que tu as fait n'importe quoi et tu signales que le schéma est pas bon. Je pense que c'est plus sain pour espérer pouvoir un jour séparer les deux cas proprement.

On est d'accord que si c'est pour revendre la startup à une grosse boîte dans six mois, le booléenv c'est sans doute plus simple, mais j'ai peut-être été enduit d'erreur par le mot clé "bonne pratique" dans la question initiale.