PHP|Débutant :: Forums

Bonjour,

Je vous le dit en toute sincérité, il n'est pas sérieux d'envisager un tel projet dans un contexte MySQL, et d'autant plus dans un contexte "médical". Envisagez même SQL Server Express (gratuit) plutôt que postgreSQL. Si vous en voulez les raisons vous pouvez me contacter par Skype: pseudo: admin_tseonline.

Si une extension de projet correspond à un type d'amendement, alors oui sans hésitation: supprimez les entités projet_extension et wp_extension et remplacez-les par votre entité AMENDEMENT.

Par contre évitez le domaine ENUM qui est une dénormalisation que je déconseille vivement. Il est préférable de créer une table de paramétrage pour définir les types au même titre que l'entité ROLE du modèle que je vous ai fourni. C'est la table correspondante qui servira à remplir un selectbox de votre formulaire de saisie. A chaque type vous aurez son id_technique que vous pourrez communiquer à la base. (essayez de communiquer que des entiers de préférence dans un contexte web).

Votre modèle est dangereux et me semble inexact par rapport à ce qui a été dit.
Il ne peux y avoir de dépendance directe entre un projet et un "subcontractor". En effet seul les partenaires sont autorisés à intervenir sur un projet. Un sous-traitant quant à lui n'interviendra que pour le compte du partenaire autorisé pour un projet donné, et accepté préalablement comme tel dans le système pour être en mesure d'effectuer un travail sur un wp donné.
Votre modélisation d'adresse ne gère pas d'historique non plus. C'est toujours la dernière en vigueur qui est prise en compte, ce qui va vous obliger à gérer de la redondance à ce niveau par rapport à la gestion d'historique de facturation. Vous allez rendre votre système moins performant et plus "obèse" que nécessaire.

++

EDIT: Vous y gagnerez beaucoup sur un projet d'envergure comme celui-ci à créer un référentiel d'adresse unique pour l'ensemble applicatif et de créer ensuite une historisation par référence sur les entités où cela est requis. De plus cela vous offrira la possibilité de faire une recherche d'adresse sur l'ensemble du système en quelques ms quelque soit la volumétrie à terme de votre solution.

Dernière modification par Jc (30-09-2014 17:37:58)

@Pierrot: J'utilise autant postgreSQL (qui est libre) que SQLServer. MySQL je l'ai laissé tombé y a un peu plus de 2 ans maintenant, car il ne me permet pas d'assurer la qualité de service que j'ai besoin de fournir et que mes clients me demandent. J'essaye d'utiliser les outils adaptés aux exigences techniques requises, et en toute objectivité, sinon je ne pourrais pas être/rester crédible au niveau maîtrise d'ouvrage et des recommandations techniques faites pour la maîtrise d'œuvre (et d'autant plus quand je dois prendre la responsabilité globale sur le projet et fournir des garanties à ce niveau.)

PostgreSQL est souvent très bien et suffisant pour beaucoup de projets, mais reste trop limité techniquement pour d'autres.

++

Dernière modification par Jc (30-09-2014 15:49:59)

Oui je sais c'est un argument récurrent. J'ai juste pas les moyens d'avoir une infrastructure surdimensionnée et je ne dispose que de 24h par jour pour gérer ce que j'ai à gérer. Pas envie de faire compliqué quand je peux faire simple et quand le jeu n'en vaut pas la chandelle.
Quand on développe en base de données épaisses on apprends vite à connaître les limitations réelles d'un moteur de SGBDR et ce qu'il vaut

EDIT: Qui dit limitations réelles, dit possibilité de faire ou pas, sans chercher à savoir si c'est compliqué ou simple: vues matérialisées, parallélisme, gestion des verrous, qualité isolation des transactions, tolérance 0 en termes de pertes de données, gestion des espaces disques, limitations analyseur plans de requêtes (qualités et performances algorithmes), respect conformité standard SQL, gestion CTE, fonctions de fenêtrage, capacité de montée en charge en accès concurrentiels, gestion Xquery natif, gestion FullText intégrale, etc...

Dernière modification par Jc (01-10-2014 14:03:51)