Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Avis sur MCD Immobilier avec WD18
Bonjour à tous.
Après avoir pas mal cherché sur le net et sur le forum, je pose mon problème.
J'ai déjà posé la question sur le forum MERISE mais puisque j'au réalisé ce MCD avec Windev (18), je souhaitais quand même demander à des habitués de Windev.
Je dois réaliser un MCD pour une agence immo.
Gestion des clients, des prestations assurées (mise en vente, photographies...) et procéder à une description du bien étage par étage, pièce par pièce.
Qu'en pensez vous ?
Personnellement je ne créerais pas une table étage, mais je placerais juste un attribut étage sur la table pièces quitte a avoir une table TypeEtage si l'on veut normalisé le contenu de l'attribut.
Sujet connexe : dans le MLD, je te conseille de nommer tes tables et colonnes de manière normalisée.
Voir par exemple :http://sqlpro.developpez.com/cours/standards/#L3
Cad normaliser ?Envoyé par DelphiManiac
La table étage ne peut pas me permettre justement d'énumérer plus facilement le nombre d'étage d'un bien ?
Je vais faire la table TypeDeBien aussi (maison, appart, garage etc.) et dans les pièces et le terrain, j'aimerai inclure des équipements du genre "cheminée" ou "piscine"...
Je suis contre cette proposition. Si l'entité a une existence il faut la créée en tant que tel. Ce que tu gagnes peut être en conception tu est sur de le perdre en maintenance
Bonjour,
Pour les tables Client, Commande, Prestation, Bien Immo
tu dois ajouter une rubrique "Reference" car tu verra avec la mise en pratique que ton client aura besoin d'une référence qui n'est ni le nom ni l'ID.
Ensuite je suis assez d'accord avec l'idée que chaque entité doit être une table donc T_Parking est une table et T_Balcon et T_Jardin sont des tables séparées.
De plus prenons le cas de T_Parking :
tu dois aussi avoir une table T_TypeParking car si tu laisse le type (place, garage,box etc...) comme un champ de la table T_Parking tu vas forcement un jour ou l'autre te retrouver avec des doublons , des erreurs d'orthographe etc... donc tu crée une table T_TypeParking et tu choisis le type avec une combo dans la fiche Prking.
Donc ton analyse est un bon "premier jet" mais tu dois encore la travaziller un petit peu.
Bon dev
Dans mon esprit, la place de parking étant rattachée au bien immo de même q'un terrain ou qu'une cave, je comptais créer un table T_EQUIPEMENT_BIEN elle même rattachée à une T_Type_equipement_bien (garage, parking, box, jardin, piscine etc.). Pas bon ??
J'ajoute que je comptais aussi créer une table T_PIECE générique, associée à une table T_TYPE_PIECE.
Dois-je en conclure qu'il serait plus juste de créer les table T_SALON, T_CHAMBRE etc... ?
En fait je pense qu'il faut raisonner selon les options possibles d'une pièce.
Entre un salon ou une chambre il n'y a pas beaucoup de différence (voir pas du tout) Pour une cuisine on peut imaginer quelques options, pour parking aussi.
J'imagine que ton approche avec une table T_EQUIPEMENT_BIEN n'est pas si mal car on ne va pas avoir tant de tuple que ça.
Alors je dirai ok pour cette approche, pas la peine de faire une usine à gaz.
Le tout est de bien raisonner entre l'ouverture et l'adaptabilité que te donne une analyse ou chaque type d'entité est traduite par une table et la facilité d'appréhension d'une analyse simplifiée ce que tu semble vouloir utiliser.
Si ta table simplifiée ne contient qu'une centaine d'enregistrements ta solution n'est pas mauvaise.
oh oui, j'en aurai pas beaucoup plus. Et puis j'ai surtout peur qu'en faisant des tables propres aux types de pièce(T_SALON, T_CHAMBRE...), avec toutes les options inhérentes à ce type, il reste beaucoup de champs laissé vides...
Là au moins, la pièce est générique, et on choisis directement les options qui seront saisies.
Une question purement structurelle me taraude l'esprit.
J'ai lu le tuto MERISE, et j'ai cru comprendre que dans ma table PIECE devait apparaitre, en plus de la clé étrangère #IDEtage (car une pièce se trouve dans un étage) la clé étrangère IDBienImmo...
N'est-il pas suffisant de "situer" la pièce grâce à son #IDEtage, qui lui est "situé" grâce à son #IDBienImmo ?
Si cette clé (#BienImmo) a bien sa place dans la table PIECE, est-il nécessaire de faire une liaison dans l'analyse de Windev ?? (Ou peut-on juste créer la clé à la main ?)
merci
Bonjour,
par expérience puisque c'est aussi mon domaine d'activité et que j'ai eu aussi à faire ce développement, le plus simple est le mieux. Tout doit être visible rapidement car il y a beaucoup d'échanges au téléphone et les infos doivent être visibles sur l'ensemble du bien directement.
Sur un écran tu dois pouvoir présenter toutes les pièces et leur contenu sans aller dans des fenêtres filles le détail des pièces.
Pour faciliter la saisie des biens, j'ai opté pour des zones libres avec seulement quelques champs indispensables (mais pas obligatoires) qui décrivent le bien mais pas le contenu (surfaces (totale du bien, terrain, balcon, grenier, terrasse ...) , orientation, niveau, nb de pièces, nb de chambres, type de chauffage, ..., prix de vente, frais de vente, date de dispo, ...).
Ensuite j'ai prévu de décrire plus précisément le bien par des fenêtres filles pour chaque élément, sans précision de ce que ça peut être (parking, chambre, salle de bain, cuisine, cabane de jardin, piscine ...)
Les zones sont en saisie uniquement (avec la pré-saisie je n'ai pas de doublon !) et très minimalistes : type, surface, description, observations.
Il faut avoir en tête qu'un client peut acheter un parking ou un garage seul et donc la table de bien doit pouvoir prendre en compte cela aussi (d'où les zones non obligatoires).
Bref il y a plein de cas possibles qui se présentent et je ne suis que dans la partie promotion et non agence immo avec les spécificités qui y sont propres ...
Au final je n'ai que 2 tables qui me permettent de décrire le bien + le contenu.
La principale qualité de l'appli doit être sa rapidité à présenter la liste des biens liées à certains critères de recherche et présenter une fiche la plus complète possible sur l'écran du bien.
Bon courage,
Nicolas
Merci pour ta réponse Nicolas.
Quand tu parles de pré-saisie, c'est à dire que pour les types de contenu que tu ajoute (jardin, chambre etc.) il y a quand même un choix imposé, avec une liste quelque part et que tu ne peut choisir qu'un élément de la liste ??
Et cette liste de choix n'est pas dans une table ?? cela m'étonne. Car comment faire évoluer le système ? A moins de prévoir une liste vraiment très exhaustive !
Je prend bonne note de ton conseil concernant la visibilité de la globalité du bien en une seule fenêtre, et effectivement, s'il y a de nombreuses tables, pas évident de requêter partout !
La pré-saisie, c'est lorsque tu commences à taper dans la zone, WinDev va chercher les entrées dans la table qui commence par les mêmes caractères et te propose la fin (saisie assistée en fait). Je n'impose pas de choix car dans l'ERP que j'ai fais j'ai mis une liste et il y a toujours des entrées à rajouter ...
La liste est alimentée au fur et à mesure par la saisie dans la base des biens et des contenus (pièces, annexes, équipements, ...).
Les listes exhaustives, j'ai abandonné l'idée depuis quelques années. Les tables sont toujours polluées par des entrées multiples : type 4, type 4 duplex, type 4 + (parce que grenier aménageable ou je ne sais plus quoi !), type 4/5, duplex type 4 (pour te donner des exemples).
Lorsque je le mets entre de nouvelles mains, je dis clairement qu'il y a forcément un type sur le bien et qu'il est fortement conseillé de ne pas en rajouter mais de mettre toutes les remarques dans la case description du bien !
Ok, j'ai compris, c'est vraiment pas bête en fait !
merci
Répondre avec citation
Partager