Discussion :

[skit]

Bonjour/Bonsoir à tous,
j'ai un gros problème dans la conceptualisation d'un site de gestion pour une association de soins aux handicapés (mêlant donc gestion de pensionnaires, de personnel, d'activités, de stock,...). Autant vous dire qu'après réalisation du MCD, l'application est un sacré sac de noeuds.

Pour faciliter l'accès aux membres du personnel, l'application sera située sur un petit serveur interne et est développée en php/ajax/mysql.

Pour faciliter son développement, j'essaie de réaliser un tableau reprenant toutes les informations et les traitant automatiquement en permettant l'édition des informations en ajax.
Une variable multidimensionnelle garde en mémoire le nom du champs dans sa balise, dans la table d'où il provient, à afficher dans le thead,... Il doit contenir, ensuite, les paramètres de contraintes des champs (les paramètres permettant de relier la valeur entrée à des tests à effectuer avec jquery pour vérifier la validité du champs avant de l'envoyer) mais tout ça me pose tout de même un problème car il ne s'agit pas de l'édition d'une table mais d'un sac de noeuds.

Comment réaliseriez-vous ceci simplement de façon à pouvoir gérer les clés secondaires? Exemple simple: une personne ayant une adresse possède un code postal lié à une ville. Je n'arrive pas à envisager de solution simple pour gérer cette table secondaire par ce système censé être automatisé (dépendant uniquement de la variable multidimensionnelle initiale)

Auriez-vous une idée pour me sortir de ce casse-tête?

[SQLpro]

Faire des contrôles coté client à des limites que la base n'a pas. par exemple il est impossible de pré vérifier côté client l'unicité d'une données.
De ce fait, tout contrôle poussé envisagé côté client est farci de chausses-trappes et vous demandera un travail colossal alors que le SGBDR fait tout ce travail de manière automatique via les contraintes !

Vous faites fausse route sur votre dev.

A +

[fsmrel]

Ave,

Auriez-vous une idée pour me sortir de ce casse-tête?

Ne tricotez pas le Comment et le Quoi : les données ; commencez par réaliser un MCD, en ayant le souci d’urbaniser : traitez thème par thème (référentiel PERSONNES, référentiel STOCKS, référentiel ACTIVITÉS, etc.), transformez en somme ce qui ressemble à un produit. Ces histoires de variable multidimensionnelle, php/ajax/mysql, tout cela est orthogonal à votre problème.

[skit]

Merci beaucoup pour vos réponses et désolé de ma longue réactivité: mes études sont très prenantes et prioritaires
Malheureusement, vos indications ne me permettent toujours pas de trancher le noeud gordien.

Faire des contrôles coté client à des limites que la base n'a pas. par exemple il est impossible de pré vérifier côté client l'unicité d'une données.
De ce fait, tout contrôle poussé envisagé côté client est farci de chausses-trappes et vous demandera un travail colossal alors que le SGBDR fait tout ce travail de manière automatique via les contraintes !

Vous faites fausse route sur votre dev.

A +

Je suis bien d'accord avec vous et des contraintes, notamment d'unicité, existent côté serveur mais je dois pouvoir rendre abordable cette information côté client pour éviter qu'il ne se trouve face à un message d'erreur sans plus d'info. Qui plus est, certaines autres choses me semblent plus délicates côté serveur comme la comparaison de deux timestamps (type int) pour s'assurer que l'un est toujours plus grand que l'autre ou, étant donné que les tables sont relationnelles, comment traiter un code postal qui n'est pas encore entré s'il se rapporte à une ville qui doit être rajouté dans une table externe? Ou, autre exemple, l'édition du type de soins ou d'activités que le résident peut se voir attribué et qui sont liés à d'autres tables séparées.

Qui plus est, un LIKE n'est pas aussi puissant qu'une regexp pour s'assurer que le numéro de téléphone ou l'adresse mail est au bon format et le message d'erreur renvoyé sera un échec dans l'exécution de la requête ce qui s'apparentera à un bug pour l'utilisateur

Ave,



Ne tricotez pas le Comment et le Quoi : les données ; commencez par réaliser un MCD, en ayant le souci d’urbaniser : traitez thème par thème (référentiel PERSONNES, référentiel STOCKS, référentiel ACTIVITÉS, etc.), transformez en somme ce qui ressemble à un produit. Ces histoires de variable multidimensionnelle, php/ajax/mysql, tout cela est orthogonal à votre problème.

Les MCD, MLD et MPD ont été réalisés, sont épurés de tous cycles et respectent les 3 règles de normalisation des données ainsi que les propriétés ACID. Je pense que le problème est déjà bien dimensionné, il s'agit surtout de ma difficulté à utiliser de l'information conceptualisée selon des règles dont je n'ai pas l'habitude.