tu parle de "mapping" ... comme c'est etrange ... ;)
puisque Merise est en chute libre, parlons d'UML . comment modelise tu un diagramme de classes de données avec heritage multiple ?
l'ordre de la dizaine ... d'accord ... si je te dis chiche ?
sachant que j'ai posé le contexte jusqu'au paquet de nouille dans carrefour, je te propose d'implementer ta solution de "l'ordre de la dizaines de table" pour un carrefour classique ( mais virtuel ) qui dispose d'une quarantaine de caisse (dont il a besoin pour encaisser et non decorer ), qui gere son stock ( operation de cout technique du stock et de gestion ) avec les dates de limite de vente et de consommation ( operation comptable de depreciation des stocks ), les passages à la caisse, et les vols en tout genre ( perte seche assuré ), gestion des taxes ( TVA, IS, CSG, RDS ), gestion des RH ( horraires, salaires, primes, heures sups, ... ), gestion des provision sur risque ( incendie, hygiene, innondation, ... ) je te pose le plan comptable en vigueur en france cad le PGC 99, et nous n'aborderons pas les normes IAS. je te simplifie les choses en disant qu'il n'y a pas de pertes aux changes, cad que tout operation est en monnaie locale, et que les problemes de consolidation et d'integration ne se posent pas non plus.
tout ca tiens sur des graphes, par contre, le fait de le faire sur un modele relationnel devient tout d'un coup plus embetant :)
les SGBDO sont une alternative au relationnel "dur" pour les problematiques autour des arbres et des graphes. mais regarde LDAP + LDIFF, les implementations sont assez absconses et lourde.
Pour du XML, tu as Xindice de Apache, qui a du mal avec des fichiers XML de plus de 5 Mo . il y avait un projet d'Ideal-X sur les SGBD XML .
[^] # Re: explosion du trokilometre
Posté par Mouns . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
puisque Merise est en chute libre, parlons d'UML . comment modelise tu un diagramme de classes de données avec heritage multiple ?
l'ordre de la dizaine ... d'accord ... si je te dis chiche ?
sachant que j'ai posé le contexte jusqu'au paquet de nouille dans carrefour, je te propose d'implementer ta solution de "l'ordre de la dizaines de table" pour un carrefour classique ( mais virtuel ) qui dispose d'une quarantaine de caisse (dont il a besoin pour encaisser et non decorer ), qui gere son stock ( operation de cout technique du stock et de gestion ) avec les dates de limite de vente et de consommation ( operation comptable de depreciation des stocks ), les passages à la caisse, et les vols en tout genre ( perte seche assuré ), gestion des taxes ( TVA, IS, CSG, RDS ), gestion des RH ( horraires, salaires, primes, heures sups, ... ), gestion des provision sur risque ( incendie, hygiene, innondation, ... ) je te pose le plan comptable en vigueur en france cad le PGC 99, et nous n'aborderons pas les normes IAS. je te simplifie les choses en disant qu'il n'y a pas de pertes aux changes, cad que tout operation est en monnaie locale, et que les problemes de consolidation et d'integration ne se posent pas non plus.
tout ca tiens sur des graphes, par contre, le fait de le faire sur un modele relationnel devient tout d'un coup plus embetant :)
les SGBDO sont une alternative au relationnel "dur" pour les problematiques autour des arbres et des graphes. mais regarde LDAP + LDIFF, les implementations sont assez absconses et lourde.
Pour du XML, tu as Xindice de Apache, qui a du mal avec des fichiers XML de plus de 5 Mo . il y avait un projet d'Ideal-X sur les SGBD XML .
pour les graphes, ...