Discussion :

[Atronach]

Bonjour,

Je dois développer une application de gestion de nomenclatures pour calculer des prix
j ai regardé la doc sur l arborescence et les métadonnées

donc au niveau des nomenclatures :
une nomenclature peut posseder plusieurs sous nomenclatures ou articles
il y a des sous ensembles
un article peut faire partie de plusieurs sous ensembles

comment bien représenter ça ?
faut il vraiment prendre la representation intervallaire ?

apres pour le choix entre access, sql server (ou mysql) que me conseillez vous ?

ce sera une appli pour maxi 5 personnes donc je pensais access, mais je sais pas si je vais etre limité pour les requetes du genrer : afficher la nomenclature, et les n sous nomenclatures (en précisant le niveau si possible)

merci

[ylarvor]

Je dois développer une application de gestion de nomenclatures pour calculer des prix
j ai regardé la doc sur l arborescence et les métadonnées

L'article de SQL Pro sur les meta données, je l'ai lu. Mais quel est cet article que tu cites sur l'arborescence ?

[Atronach]

http://sqlpro.developpez.com/cours/arborescence/

celui sur la représentation intervallaire

[ylarvor]

La question que tu dois te poser, c'est le nombre de creation/mises à jour et le nombre de requete de selection par jour que tu vas avoir... la representation intervalaire est interessante pour des volumes important d'interrogation et des arbres complexes. Si tu as 5 utilisateurs, on peut supposer que la performance n'est pas indispensable et une representation classique par auto jointure est suffisante.

La representation intervalaire implique en mise à jour l'utilisation de procédure stockée ce qui répond à ta second question : sql serveur ou access. Si tu utilises la representation intervalaire, mieux vaut sql serveur pour pouvoir proceder par procedure stockee.

voila ce que j'en pense.

[Atronach]

oki merci pour les informations.

donc ce serait plus access le choix.

[ylarvor]

regarde bien les prerequis de SQL Pro sur l'intervallaire et compare les à ton arborescence finale.
si tu choisis l'intervalaire, prends sql server.

[Atronach]

bah je dois avoir un millier de lignes pour les produits et 5 6 niveaux maxi je pense

apres je sais pas comment bien faire les requetes pour recuperer toutes les infos avec l autojointure

edit :

C'est pourquoi ce modèle est a proscire lorsque :

l'arbre est profond (plus de 5 niveaux)
l'arbre est large (plus de 100 éléments sur un même niveau)
l'arbre contient beaucoup de valeurs (à partir de 200 à 300 éléments)
la majorité des requêtes sont des requêtes d'interrogation - SELECT (au moins 50% des requêtes)
Et personnellement je vous conseille de passer au modèle par intervalle dès que l'un de ces 4 critères est vrai !

oki, et on peut faire des etats sous access avec comme bdd sql server ? ou il faut passer a un client web, java ou autre ?

[ylarvor]

tu as un super forum sur le produit Access pour t'informer sur les etats ( formulaire ):
http://www.developpez.net/forums/forumdisplay.php?f=45

Concernant les auto jointure, il s'agit d'un problème de programmation.

Quel est ton langage ? il est probable que tu sois oblige de passer par le concept de recursivité... ce n'est pas forcement simple à comprendre mais c'est puissant...

http://recursivite.developpez.com/

Bon courage.

[Atronach]

au niveau langage ça va je connais php, html, java, c, c++ (enfin les cours d'iut info ^^) et donc la récursivité

et possibilité d apprendre donc le vba / vb6 sur le tas (je pense faire ça si je choisis l utilisation d access)

enfin merci quand meme pour les liens et les réponses.

[Atronach]

une derniere question :

avec sql server 2005, les requetes récursives sont bien gérées, ou il vaut mieux prendre la représentation intervallaire ?

thx

[ylarvor]

D'apres SQL Pro, le transac SQL ne gère pas la récursivité dans les procedures stockees. Par conséquent, il est nécessaire de gérer la récursivité dans ton langage de programmation préféré si tu choisis l'auto jointure.

[ylarvor]

Un extrait de mon blog qui explique que les requetes hierarchique ne sont plus un probleme sous sql serveur 2005 grace à l'expression de table courante... Affaire à suivre.

Une expression de table courante ( CTE pour common Table Expression ) ressemble beaucoup à une vue non persistante.
Syntaxe :
WITH nom_CTE ( nom_colonne,... )
AS
(
requete
)
SELECT * FROM nom_CTE
Exemple de code :
WITH selection AS (
SELECT identificateur_de_cellule,traffic,datepart(ww,date) as sem,ROW_NUMBER() OVER (PARTITION BY identificateur_de_cellule,datepart(ww,date) ORDER BY traffic) as OrderRank FROM TRAFFIC_CELLULES
)
SELECT * FROM selection where OrderRank < 3
Exemple de code :
Use AdventureWorks
GO
WITH OrderCountCTE(SalesPersonID,OrderCount) AS (SELECT SalesPersonID,Count(*) FROM Sales.SalesOrderHeader WHERE SalesPersonID is Not Null GROUP BY SalesPersonID )
SELECT sp.SalesPersonID,oc.OrderCount,sp.SalesYTD
FROM Sales.SalesPerson sp INNER JOIN OrderCountCTE oc
ON oc.SalesPersonID=sp.SalesPersonID
ORDER BY oc.OrderCount
Requêtes récursives avec les CTE.
La véritable puissance des CTE émerge lorsque vous les utilisez récursivement pour effectuer des requêtes hiérarchiques sur des données structurées sous forme d'arbres.
Syntaxe :
With SimpleRecursive(field name) AS
(
UNION ALL
)
SELECT * FROM simpleRecursive
Exemple :
-- Creation d'une table avec les données sous forme d'arbre
CREATE TABLE Employee_Tree( Employee_NM nvarchar(50), employee_ID int Primary Key, reportsTo int )
INSERT INTO Employee_Tree VALUES ('Richard',1,NULL)
INSERT INTO Employee_Tree VALUES('Stephen',2,1)
INSERT INTO Employee_Tree VALUES('Clemens',3,2)
INSERT INTO Employee_Tree VALUES('Malek',4,2)
INSERT INTO Employee_Tree VALUES('Goksin',5,4)
--Requete recursive
WITH SimpleRecursive(Employee_NM,Employee_ID,ReportsTo) AS
( SELECT Employee_NM, Employee_ID, ReportsTo FROM Employee_Tree WHERE Employee_ID = 2
UNION ALL
SELECT p.Employee_NM, p.Employee_ID, p.reportsTo FROM Employee_Tree p INNER JOIN SimpleRecursive A ON A.Employee_ID = P.ReportsTo
)
SELECT sr.Employee_NM AS Employee, et.Employee_NM As Boss FROM SimpleRecursive sr INNER JOIN Employee_Tree et ON sr.ReportsTo = et.Employee_ID