|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
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 |
|
|
00
|
|
|
#2 | |
|
Membre Expert
![]() ![]() |
Citation:
|
|
|
00
|
|
|
#3 |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
|
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() ![]() |
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. |
|
00
|
|
|
#5 |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
oki merci pour les informations.
donc ce serait plus access le choix. |
|
|
00
|
|
|
#6 |
|
Membre Expert
![]() ![]() |
regarde bien les prerequis de SQL Pro sur l'intervallaire et compare les à ton arborescence finale.
si tu choisis l'intervalaire, prends sql server. |
|
00
|
|
|
#7 | |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
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 : Citation:
|
|
|
|
00
|
|
|
#8 |
|
Membre Expert
![]() ![]() |
tu as un super forum sur le produit Access pour t'informer sur les etats ( formulaire ):
http://www.developpez.net/forums/f45/logiciels/microsoft-office/access/ 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. |
|
00
|
|
|
#9 |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
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. |
|
|
00
|
|
|
#10 |
|
Invité régulier
![]() Inscription : janvier 2007 Messages : 22 ![]() |
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 |
|
|
00
|
|
|
#11 |
|
Membre Expert
![]() ![]() |
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.
|
|
00
|
|
|
#12 | |
|
Membre Expert
![]() ![]() |
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.
Citation:
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com