Reprise du message précédent :
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.

2 tables ca  veut dire aussi les formulaire / url différentes, les scripts de transferts de données  
 

Il s’en fout ça flaie, il aura balancé ça à la TMA bien avant  

Vrais savent, surtout ce genre d'app qu'un stagiaire avec un sticker elephpant et wordpress sur son laptop toshiba peut maintenir

Sachant que les prospects sont potentiellement des futurs clients je vois pas le soucis de les mettre dans la même table perso.

Tenez les ceux qui sont bien dans les écosystèmes USB-C / TB4, ça existe des hubs multi-ports de bonne qualité qui savent faire du PD sur plus d'un port? Je vois beaucoup qui font du full PD sur 1 port mais ne sortent que 7.5 sur le reste.

Le seul problème potentiel que je verrais c'est que tu peux bloater ta table de clients avec des prospects, et faut bien penser à filtrer à chaque fois.

Par contre une suggestion que j'ai pas vu (mais peut-être raté) c'est de sortir une table "prospect" avec les champs communs et d'avoir la table client qui a une FK sur les prospects, comme ça convertir un = prospect en client est simple (tu crées une entrée dans la table client), la confusion entre clients et prospects est limitée (la seule confusion possible c'est quand tu veux trouver des prospects spécifiquement, donc qu'il faut t'assurer que ce ne sont pas des clients), avoir un client complet ajoute juste un left inner join basique, la gestion des trucs communs est uniforme, et quand tu drop une entrée de la table prospect ça drop le client correspondant s'il y en a un.

Parle en sur le topic MacBook et tag Dandu mais je crois que c’est pas possible sur deux ports.

 
 
Y’a un where à ajouter c’est pas la mort. Selon l’orm ça peut même être automatique.

On avait des hub startech avec 100W à la cogip, mais ça dépends combien le laptop suce,  les MBP prenaient quasi tout

 
On a un truc similaire dans notre schéma pour une relation similaire, j'aime beaucoup comme modélisation.

C'est la solution 3 en faisant l'hypothèse que personne == prospect. Ça marche si l'hypothèse n'est pas trop foireuse.

ça marche très bien, mais sémantiquement j'aime moins. Quitte à retoucher la structure je passerais carrément par une abstraction type "personne", histoire de conserver une différence entre un prospect devenu client et un client "spontané". Suivant l'objectif de l'ajout de prospects dans la base ça peut être une info pertinente et ça coute probablement pas grand chose de plus.

J'arrive peut-être après la guerre, j'ai pas tout lu, désolé si je réponds à côté de la plaque

Je ne sais pas quel lib est utilisée, mais avec Doctrine je ferais 2 entités branchées sur 1 table avec un champ discriminant.

Ensuite c'est lui qui s'occupe de requêter les bons champs.

https://www.doctrine-project.org/pr [...] pping.html

Je suis assez d'accord, notamment si l'appli doit être maintenue dans le temps. Tu vas te retrouver à terme avec pleins de champs sur Clients qui devront être nullable (ou de relâcher d'autres contraintes similaires coté DB), sans doute par la suite avec le cas inverse, parce que j'ai du mal à croire qu'à terme t'auras pas besoin de stocker des infos spécifiques aux prospects (encore une fois, je me place dans le cas d'une app qui va vivre et évoluer, pas d'un projet qui doit être retiré).

Bref, pour moi avec cette solution, tu relâches clairement les contraintes coté DB... Sauf que ce que tu contrôles pas coté DB, ça finit in fine par se retrouver dans le code applicatif. Perso, tant que je peux, je préfère que ce soit la DB qui me pète à la gueule le jour ou j'essaye de sauver un Client sans code SIRET, plutôt que de devoir le rendre NULLable (parce qu'on l'a pas pour un prospect) et faire confiance que les devs oublieront JAMAIS de rajouter un "if" dans le code au moment de sauver un Client pour vérifier que son SIRET est bien là. Parce que là, toi maintenant que t'as le sujet en tête t'y pense, et t'as peut être qu'un seul endroit dans le code où tu sauves un Client, avec une poignée de champs seulement de différence, du coup c'est facile et bien sur "meuh non, personne fera jamais l'erreur de sauver un Client sans SIRET, en plus ça ferait péter la facturation en fin de mois "

Dans 2 ans, quand t'auras eu entre temps 10 autres projets dans la tête, que y a des dizaines de nouvelles subtilités entre ton Client et ton Prospect, et que c'est un dev nouveau qui reprend une petite fonctionnalité a priori mineure ? Sans doute moins facile de garantir à 100% que ton contrat "le SIRET de mon client DOIT être rempli" soit respecté. En plus c'est un problème insidieux, parce que si in fine tu te retrouves avec des Clients sans SIRET, c'est pas au moment ou tu l'ajoutes que tu vois le problème, mais au moment ou la feature qui se base sur ce point va péter... Ce qui peut se produire des semaines ou des mois après l'introduction du bug, ce qui complique la compréhension du bug ainsi que la solution.

Bref, encore une fois pour moi solution à 2, voir 3 tables pour les champs communs, surtout qu'encore une fois, avec la plupart des FW moderne, c'est quasi transparent coté code applicatif de savoir si tu dupliques tous tes champs communs dans les 2 tables, ou si tu factorises dans une 3ème. Ca devient en gros un choix entre perdre de la place en DB, ou faire plus de jointures dans tes query. Ex avec Django: https://docs.djangoproject.com/en/3 [...] nheritance (désolé je connais pas les FW PHP)

On a regardé Black widow (film pas top malgré un super casting).
Y’a une jeune fille, je me dis : c’est dingue, elle a les mêmes yeux et les mêmes expressions que Mila Jovovic
. Et c’est bien sa fille en fait (le père peut rentrer chez lui, il a laissé 0 gênes d’apparence à sa fille )
 

 
C’est un des trucs que je trouve difficile en info, parce que c’est une loterie :
- dans 2 mois le métier arrive avec une notion de “parrain”, ou de revendeur, ou de groupement de clients, et t’es rudement content d’avoir modélisé propre avec une “personne”
- ou alors ça vient jamais, et tu as perdu du temps, en te rajoutant une taxe sur tous tes dev futurs avec une modélisation presque trop complexe.
 
Et c’est vraiment dur de le savoir à l’avance

 
ok.
 
C'est quoi le bloc qui a l'air inamovible au milieu du mur de droite (j'imagine que ça correspond à l'emplacement de la cheminée, mais pas sûr) ?  
 
Si c'est effectivement inamovible :
 

• est-ce qu'on peut faire passer des canalisations "à travers" le long du mur de droite (celui où il y a la cheminée)
• C'est quoi les dimensions et les distances aux murs.

Autre question bête : l'accès à la terrasse, c'est une fenêtre? Sur le plan, ça faut 136 de haut avec une allège à 340. Les 340 correspondent à un seuil, ou le sol de la terrasse est plus haut que le plancher?  
 
 

Ça dépend des raisons:
 
- Si c'est parce que c'est trop obscur que dès que t'y touche (si tu t'es enduis d'eau bénite avant) la société dévisse en bourse, y'a effectivement pas de quoi être fier.
- Si c'est parce que c'est une petite unité de code qui fait un truc et qui le fait bien, je vois pas le soucis.

https://twitter.com/fasterthanlime/ [...] 8195341314
 

 
https://imgur.com/a/3LT6NpQ
les cercles rouges sont des cheminées, c'est un peu incertain encore ce que je peux faire passer dedans et quels côtés sont pour moi et pour le voisin.
Mais je vois que le câble de la télé passe dans la cheminée de la terrasse, et ma hotte sort dans la cheminée de la face nord.
 
oui, l'accès à la terrasse se fait par 2 marches, à travers d'une fenêtre. le plancher et la terrasse sont à peu près au même niveau, y'a des détails que j'ai pas modélisés.

 
Moi aussi j'aime bien le   le lundi alors je rajoute ça https://e.pcloud.link/publink/show? [...] 0FSFKQzp57

 
ok
 
Mais à l'intérieur de la pièce, le bloc qu'on voit sur la photo (là où il y a un petit cadre et 2 interrupteurs), ça peut se démolir ou pas?  
 

c'est un placard, à dégager.
le centre de l'espace est entièrement libérable.

Il y a des gens qui habitent à Lyon ici ?
 
Il me semble que rati est dans le coin mais pas à Lyon même.

Explique direct ce dont tu as (ou aurais éventuellement si tu peux pas donner les détails en public) besoin, ça se trouve quelqu’un pourra directement te répondre ou t’orienter.

Il vivait sous une pierre depuis le début de l'année ?

 
rati est a lyon et va avoir un appart a vendre pas cher quand il aura trouvé son moulin
Je suis à 1h de Lyon

 
ok, ca aide bien.

J'y emménage début décembre, je prépare la première ki

du coup entre lille et metz, finalement tu pars à lyon  

https://twitter.com/paltrowginette/ [...] 3778976769
C’est toi ?

Vaise coast    
 
Donc Lyon 9è  

Rêve

Ma nana a décroché un boulot pas loin. Ça c'est fait très vite et elle n'a qu'un mois de préavis.

Il posait des questions sur les employeurs il y a quelques temps, il pleurait sur le prix des loyers la semaine dernière

Apparemment ils vont va être deux sur le loyer, ça compense.

 
 
C'est pour ça que j'ai dit que ça dépendait des cas. Un truc back qui fait le job 6 mois, y'a pas de raisons qu'il ne le fasse pas 10 ans après. (Oui les maj blabla).
 
là où je voulais en venir, et surtout pour le web, c'est que j'ai aucune fierté à me dire, ptin le site que j'ai fait tourne encore 10/20 ans après. Bien au contraire, j'suis content qu'il ait évolué quoi. Ne serait-ce qu'au point de vue sécu, UI ou autre.. Enfin j'suis pas le genre à me dire "wah je suis vraiment le meilleur dev du monde, le code fonctionne encore". Bah non, y'a 99% de chance que n'importe qui, qui relie son code ou autre se dise, p'tin c'est merdique.
Mais bon, temps que ça fonctionne.

 
 

 
un truc dans ce genre là? L'idée c'est de se dire qu'avec un placard en face de la porte de la chambre, elle a pas besoin d'être immense.. Mais ça peut dépendre de l'usage : c'est un "appart d'amis" si j'ai bien compris ?  
 

J'aurai dû mettre des guillemets