Re: [Phpcompta-contrib] Question idiotes

[herve couvelard]

Bonjour,

j'ai commencer un peu le truc, je commence à voir un peu de pages....

je fais une copie du mail qui a l'air d'avoir disparue de la liste.
il y a quelques fichiers à modifier de-ci de-la, plus quelques 
modification de php.ini + apache.conf

j'avancerais un peu la semaine prochaine et je ferais le point sur mes 
idées/problèmes/soucis/ tonsure ;-)

Bon WE à tous

hervé


copie mail précédent ---------------------------------------
Bonjour,

La gestion des contraintes ? les contraintes doivent de toute façon être 
géré par le code non ?

Si tu fais une demande d'enregistrement hors contrainte, il y a une 
erreur et l'opération n'est pas réalisée, mais le fait que l'opération 
ne soit pas réalisée (et sauvegarde ton intégrité de base) ne te 
dédouane pas que ton code doit récupérer l'erreur et avertir 
l'utilisateur non ?
Quelle est la différence avec la vérification dans le code php que la 
contrainte est respectée ?

Ok, je comprends que dans ce cas TOUTE LA CHAINE de programmation doit 
faire attention à ce qui se passe et que le code d'un autre ne peut être 
intégré sans vérification de l'utilisation de ses contraintes.

Le choix de mysl a été de faire des accès très rapide en lecture si peu 
d'écriture. Tous mes sites a base de donnée tourne en mysql, je ne vais 
pas utiliser pgsql sur une appli isolée. C'est un choix.

Je peux soit
1 - porter phpcompta sur mysql et integrer phpcompta et dolibarr
2 - ne pas porter phpcompta et dev de la compta dans dolibarr

Je ne sais pas encore ce que je vais faire.



J'ai intégrer toutes les tables. AU passage, je ne comprend pas pourquoi 
les tables de admin/sql/dossier1 et /admin/sql/mod1 sont dupliquée.

pour certaines contraintes, il y a d'autres manière de gérer

par exemple :
--------------------------------------------------------------
CREATE TABLE stock_goods (
    sg_id integer DEFAULT nextval('s_stock_goods'::text) NOT NULL,
    j_id integer,
    f_id integer NOT NULL,
    sg_code text,
    sg_quantity integer DEFAULT 0,
    sg_type character(1) DEFAULT 'c'::bpchar NOT NULL,
    sg_date date,
    sg_tech_date date DEFAULT now(),
    sg_tech_user text,
    CONSTRAINT stock_goods_sg_type CHECK (((sg_type = 'c'::bpchar) OR 
(sg_type = 'd'::bpchar)))
);
----------------------------------------------
devient
---------------------------------------------
CREATE TABLE `stock_goods` (
  `sg_id` int(11) NOT NULL auto_increment,
  `j_id` int(11) default NULL,
  `f_id` int(11) NOT NULL default '0',
  `sg_code` varchar(150) default NULL,
  `sg_quantity` int(11) default '0',
  `sg_type` enum('c','d') NOT NULL default 'c',
  `sg_date` date default NULL,
  `sg_tech_date` date default NULL,
  `sg_tech_user` varchar(150) default NULL,
  PRIMARY KEY  (`sg_id`),
  KEY `fk_stock_goods_f_id` (`f_id`),
  KEY ` fk_stock_goods_j_id` (`j_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

Mon soucis actuel est qu'il y a 3 bases de donnée distinctes et je 
n'arrive pas à le faire avec debian sarge. disons que dans une même page 
 je n'arrive pas à me connecter à 2 bases de donnée mysql.

Hervé


Jérôme Warnier a écrit :

> Tu oublies la gestion des contraintes, qui va être horrible avec MySQL.
> Moi, je persiste à penser que d'utiliser MySQL ne servira qu'à rendre le
> code plus gros, plus obscur, et plus sujet à des failles, dont
> potentiellement de la perte de données.
> Et tous les développeurs que je connais et qui utilisent couramment
> MySQL et PostgreSQL rigolent de MySQL (ou plutôt, un certain nombre de
> choses dedans ne les fait pas rire du tout).

-----------------------------------------------------
Dany De Bontridder a écrit :
> Stan Pinte writes:
>
> > On peut s'en sortir avec des constraints pour garantir la cohérence,
> > ou pas? (exemples sinon?)
>
> Non pas toujours, par exemple, avec les metadonnées (voir les fiches) les
> constraint ne peuvent faire les mêmes contrôles que des procédures 
> stockées.
> En général on utilisera alors des triggers (qui pour des raisons de 
> réutilisabilités appelera des procédures stockées)
> Par exemple aucun nouveau salaire ne peut être inférieur à une valeur 
> indiquée dans une table BAREME ni dépasser un certain plafond indiqué 
> aussi dans cette table, pour ce type de travail. Les CHECK doivent avoir 
> les valeurs en dur et ne peuvent donc pas regarder dans la table BAREME 
> pour ce travail-là quel est la valeur minimum, ni avoir de tests sur les 
> différentes valeurs en fonction du code de travail. Solution: on crée un 
> trigger (INSERT et UPDATE) qui compare la nouvelle valeur et la valeur 
> dans la table BAREME, ce trigger pourrait appeler des fonctions stockées 
> qui seraient utilisées ailleurs. Evidemment le salaire est négociable et 
> 2 personnes n'ont pas le même mais toutes seront dans les limites 
> données par BAREME
> Donc les anciens enregistrements ne sont pas affectés, les nouveaux 
> biens. La mise à niveau des anciens doit être manuelle (et dans ce 


> cas-ci c'est obligatoire) sinon un trigger dans BAREME pour modifier la 
> table SALAIRE (si possible, certaines db donneront un probleme de 
> "circular trigger")
> L'exemple n'est pas génial,  mais un cas plus réaliste serait un peu 
> long à exposer on devrait attaquer les métadonnées (voir fiche par 
> exemple) où malheureusement il y a un contrôle uniquement dans le code 
> PHP au lieu de postgres (parce que je n'osais pas utiliser des fonctions 
> trop avancées pour que le portage vers MySql reste possible)
>
> @+,
> D.