PHP|Débutant :: Forums

Bonjour,

Concernant le problème de date
Il faut bien comprendre que de dire c'est la première date qui fait foi et qu'il suffit qu'il y en ait une pour dire que la facture est envoyée, sont deux cahiers des charges distincts qui se traduisent par deux requêtes distinctes selon que l'on ait besoin de connaître la date d'envoi de la facture ou non.
Si c'est la première que tu as besoin, c'est ok, c'est noté.

Maintenant, concernant le problème du prix de la facture
Je pensais que ce problème de doublement de prix était dores et déjà réglé, mais je me suis visiblement trompé.
Déjà je te rappelle que tu as un souci de modélisation avec ta tva définie en TINYINT. Faudrait que tu m'expliques la pertinence de ce choix, car pour moi c'est tout sauf pertinent et donc source d'erreur.
Ensuite, si ta table fact_prestation n'est pas normalisée correctement, ce qui est maintenant fortement possible vu la table fact_suivi, si tu as de la redondance dans les montants payés pour une facture payée, le résultat anormal que tu obtiens est tout à fait normal. Peux-tu me donner pour une facture donnée qui possède plusieurs enregistrements dans fact_prestation, les lignes de données correspondantes que je puisse me faire une idée stp?

Voilà qui devrait résoudre tous tes problèmes.
Conseil : remplace type par stype ou autre car type est un mot réservé cf coloration syntaxique, passe en innoDB, et optimise moi tes indexs, place des contraintes de clefs étrangères et mets à jour ton modèle.

Dernière modification par Jc (16-12-2012 01:47:09)

Bonjour,

comme je te l'ai déjà dit, cela viens du fait que ton id_facture dans fact_prestation est défini en INT(11) NOT NULL au lieu de INT(10) UNSIGNED NOT NULL comme il l'est ailleurs. On ne peut pas faire de correspondance entre des pommes et des poires, d'où l'erreur que tu obtiens.

Tu peux traduire en français stp???

Tu commences à comprendre ce qu'on n'arrête pas de rabâcher avec MK sur ce forum avec les notions d'intégrité, consistance et qualité des données,
avec un problème d'intégrité référentielle pour ton problème d'erreur :

Les bases de données MyISAM en MySQL j'appelle ça des cache misère (dans plus de 90% des cas). Les imports de données rejetés à 40% par un modèle correct je connais que trop bien aussi. Donc merci, mais je ne veux surtout pas d'accès à phpmyadmin.
Pour revenir à ton problème de facture, imagine quand c'est le client qui est supprimé, la consistance des données est morte, on se retrouve avec des factures orphelines comme dans ton cas, et quand on a la chance qu'il n'y a pas un gros malin de dev qui passe par là, qui pense avoir l'idée géniale d'optimiser ses ids de clé primaire en les réutilisant (hors contexte d'une gestion cyclique des ids prévue et intégrée au cahier des charges au niveau admin), on se retrouve avec des factures appartenant avec des clients qui non jamais été facturé. Bref, tu ne peux plus te fier au contenu de tes données, car c'est l'arbre qui peut cacher la forêt. Quand ca arrive je ne touche à rien, et je demande au responsable de l'entreprise de me revalider l'ensemble des données à exporter et a réinjecter au propre dans un modèle normalisé conforme aux contraintes métier de l'entreprise. Rien de tel pour mettre une PME à genoux quand elle ne mets pas la clé sous la porte.

Les problèmes d'intégrité référentielle doivent faire l'objet d'une tolérance zéro, ca a déjà coûté des centaines de milliers voire des millions d'euros à certaines grandes entreprises, et ca continuera encore malheureusement.

Ensuite même s'il faut faire son maximum pour éviter de devoir indexer une colonne qui accepte les valeurs NULL, ton date_send en VARCHAR c'est pire, et ca peut avoir des effets de bord dans tes requêtes non négligeables. Ce genre de choses relève de la qualité de tes données.

Ensuite, de voir une facture avec une date de paiement effectué et avec un montant payé de 0 est l'illustre conséquence pourrait-on dire de tout ce que je viens de dire précédemment. A moins qu'il y ait un client qui s'est amusé à faire un chèque de zéro euro en paiement, ca fait tâche, et ca remet encore une fois en question la qualité et la consistance des données.

Pour tes deux lignes, je pense que tu es victime de ton modèle, en ayant utilisé la table de suivi comme d'un log action sur les factures. Ca te démontre aussi vu que le doc peut être envoyé plusieurs fois à des dates différentes, qu'il n'est pas pertinent d'en afficher la date d'envoi dans ton tableau contrairement à un nombre d'envoi par exemple.

Cependant pour n'avoir qu'une seule ligne sur ce genre de facture et en conservant le modèle actuel, la solution que je vois est de faire un group_concat sur la date dans la requête dérivée et faire un LEFT jusqu'au premier séparateur sur la date dans la requête principale.

++

Dernière modification par Jc (18-12-2012 13:50:53)

Normalement c'est group_concat(date_send SEPARATOR ',') et ensuite tu fais un LEFT(date_send_doc,INSTR(date_send_doc,',')-1)

Mais si c'est juste le nombre d'envoi ca sera beaucoup moins gourmand en ressources avec un simple count(date_send).

Pour le ON DELETE ca ne s'improvise pas non plus. Tout dépends ce que tu souhaites faire. Déjà il faut savoir si tu veux rendre possible la suppression d'enregistrement ou non. Si c'est non, tu mets RESTRICT par défaut. Si c'est oui, il faut mettre en place ta stratégie et que tes dépendances fonctionnelles avec tes contraintes de clé étrangère soient bien placées. Ainsi tu éviteras les risques de références circulaires lors d'une suppression qui peuvent faire des dégâts, mais c'est assez puissant car admettons que sur une structure de 200 tables une référence client ait des dépendances dans 80 tables, en supprimant un client, tu peux supprimer en même temps tout ce qui se rattache à ce client dans le modèle sans rien oublier et en préservant la consistance et l'intégrité des données, sans développer une seule ligne de code supplémentaire.

++

Bonjour,

Tous mes meilleurs voeux 2013 et surtout une bonne santé.
Pour le LEFT tu as tout ce qu'il te faut savoir dans la doc de MySQL. Si tu veux éviter des erreurs, et tout traiter au niveau de la requête (qui au final n'est peut être pas une bonne idée dans ton contexte) il te faudrait rajouter une clause CASE WHEN THEN ELSE END pour vérifier l'existence de la virgule séparatrice.
En gros s'il n'y a pas de virgule dans la colonne, on affiche la date telle qu'elle, s'il y a une virgule on affiche le contenu jusqu'à la première virgule.

++

Salut,

Une bonne année à toi aussi
Pour le LEFT, j'ai finalement compris ou tu voulais que je le met, en tombant sur une de mes requêtes ou j'en avait fait un...

Pour ma table suivi, je vois un peu ce que tu veux dire, mais j'ai du mal a voir ce que ca changerai par rapport a ma table, ca ne ferai que peu de différence je trouve, ou alors j'ai mal compris.

Merci en tt cas pour toujours me répondre