Je relance un post (http://groups.google.fr/group/
microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/
bc179a9d0a0a3073?hl=3Dfr&lnk=3Dst&q=3D#)
, suite =E0 une modification de ma liste de base et suite =E0 une
am=E9lioration que je recherche.
J'ai une table avec plusieurs champs C1, C2, C3 :
- C1 est l'iD de chaque enregistrement,
- C2 contient le nom de l'enregistrement,
- C3 renvoi =E0 un iD, appel=E9 "p=E8re".
- C4 correspond au num=E9ro de la colonne dans laquelle doit apparaitre
le champs : dans ma nomenclature, certains niveaux peuvent =EAtre vides.
Un exemple pour plus de clart=E9 :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Richard_35
Bonjour moromain,
Donc, OK, un fils ne peut avoir q'un seul père et un père peut avoir plusieurs fils (logique). Juste une précision d'analyse : je ne comprends pas pourquoi AGY, dont le père est AG apparaît en 4ème position de la nomenclature.
A bientôt, Richard.
"moromain" a écrit dans le message de news:
Bonjour à tous,
Je relance un post (http://groups.google.fr/group/ microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/ bc179a9d0a0a3073?hl=fr&lnk=st&q=#) , suite à une modification de ma liste de base et suite à une amélioration que je recherche. J'ai une table avec plusieurs champs C1, C2, C3 : - C1 est l'iD de chaque enregistrement, - C2 contient le nom de l'enregistrement, - C3 renvoi à un iD, appelé "père". - C4 correspond au numéro de la colonne dans laquelle doit apparaitre le champs : dans ma nomenclature, certains niveaux peuvent être vides. Un exemple pour plus de clarté :
Qui se transformera en : 1__2____3____4 A A__AG A__AG_______AGY A__AG__AGH A__AK B B______BC B______BC___BCJ
J'ai essayé de transformer la requête proposée par Michel, sans succès.
Une idée de modification ?
Bonjour moromain,
Donc, OK, un fils ne peut avoir q'un seul père et un père peut avoir
plusieurs fils (logique).
Juste une précision d'analyse : je ne comprends pas pourquoi AGY, dont
le père est AG apparaît en 4ème position de la nomenclature.
A bientôt,
Richard.
"moromain" <rm.acwed@gmail.com> a écrit dans le message de news:
60d5c73f-0c69-4536-ba61-dbffe7b3dc32@m34g2000hsf.googlegroups.com...
Bonjour à tous,
Je relance un post (http://groups.google.fr/group/
microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/
bc179a9d0a0a3073?hl=fr&lnk=st&q=#)
, suite à une modification de ma liste de base et suite à une
amélioration que je recherche.
J'ai une table avec plusieurs champs C1, C2, C3 :
- C1 est l'iD de chaque enregistrement,
- C2 contient le nom de l'enregistrement,
- C3 renvoi à un iD, appelé "père".
- C4 correspond au numéro de la colonne dans laquelle doit apparaitre
le champs : dans ma nomenclature, certains niveaux peuvent être vides.
Un exemple pour plus de clarté :
Donc, OK, un fils ne peut avoir q'un seul père et un père peut avoir plusieurs fils (logique). Juste une précision d'analyse : je ne comprends pas pourquoi AGY, dont le père est AG apparaît en 4ème position de la nomenclature.
A bientôt, Richard.
"moromain" a écrit dans le message de news:
Bonjour à tous,
Je relance un post (http://groups.google.fr/group/ microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/ bc179a9d0a0a3073?hl=fr&lnk=st&q=#) , suite à une modification de ma liste de base et suite à une amélioration que je recherche. J'ai une table avec plusieurs champs C1, C2, C3 : - C1 est l'iD de chaque enregistrement, - C2 contient le nom de l'enregistrement, - C3 renvoi à un iD, appelé "père". - C4 correspond au numéro de la colonne dans laquelle doit apparaitre le champs : dans ma nomenclature, certains niveaux peuvent être vides. Un exemple pour plus de clarté :
Qui se transformera en : 1__2____3____4 A A__AG A__AG_______AGY A__AG__AGH A__AK B B______BC B______BC___BCJ
J'ai essayé de transformer la requête proposée par Michel, sans succès.
Une idée de modification ?
moromain
Et pourquoi pas ?!!!! Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal un classement du type : [genre] [espèce]. Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous- espèce]. Tous les niveaux ne sont pas renseignés.
Et pourquoi pas ?!!!!
Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal
un classement du type : [genre] [espèce].
Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous-
espèce]. Tous les niveaux ne sont pas renseignés.
Et pourquoi pas ?!!!! Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal un classement du type : [genre] [espèce]. Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous- espèce]. Tous les niveaux ne sont pas renseignés.
Richard_35
Bonjour moromain,
Je n'ai pas voulu être désagréable, mais j'essaye de comprendre. Excuses-moi mais, dans ton cas, d'un point de vue analyse informatique (c'est mon métier), il ne s'agit pas de relation "père-fils" entre un animal et son [genre] [sous-genre] [espèce] [sous-espèce]. Il ne s'agit donc pas de nomenclature, à proprement parler. Je pense donc que tes tables devraient être construites de la manière suivante, ce qui résoudra ton problème par des requêtes :
Table_sous-espèce : Id_espèce : identifiant unique du espèce maître (clé1) Id_sous-espèce : identifiant unique du sous-espèce (clé2) Nom_sous-espèce
Table_animal : Id_animal : identifiant unique de l'animal Nom_animal Id_genre : identifiant unique du genre maître (clé1) Id_sous-genre : identifiant unique du sous-genre (clé2) Id_espèce : identifiant unique du espèce maître (clé1) Id_sous-espèce : identifiant unique du sous-espèce (clé2)
Structure des tables à affiner suivant les informations obligatoires de la table Animal.
Si [espèce] [sous-espèce] est lié à [genre] [sous-genre], alors il faut ajouter aux table [espèce] [sous-espèce] les clés de [genre] [sous-genre]. De cette manière, ton formulaire de création d'animal, sera composé de différentes listes déroulantes cohérentes entres elles. Ensuite, les requêtes s'effectueront facilement car les relations seront prédéfinies.
J'espère ne pas avoir été trop brouillon dans mes explications, et, encore une fois, je n'essaie juste que de t'aider. Bon courage, Richard.
"moromain" a écrit dans le message de news:
Et pourquoi pas ?!!!! Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal un classement du type : [genre] [espèce]. Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous- espèce]. Tous les niveaux ne sont pas renseignés.
Bonjour moromain,
Je n'ai pas voulu être désagréable, mais j'essaye de comprendre.
Excuses-moi mais, dans ton cas, d'un point de vue analyse informatique
(c'est mon métier), il ne s'agit pas de relation "père-fils" entre un animal
et son [genre] [sous-genre] [espèce] [sous-espèce]. Il ne s'agit donc pas de
nomenclature, à proprement parler.
Je pense donc que tes tables devraient être construites de la manière
suivante, ce qui résoudra ton problème par des requêtes :
Table_sous-espèce :
Id_espèce : identifiant unique du espèce maître (clé1)
Id_sous-espèce : identifiant unique du sous-espèce (clé2)
Nom_sous-espèce
Table_animal :
Id_animal : identifiant unique de l'animal
Nom_animal
Id_genre : identifiant unique du genre maître (clé1)
Id_sous-genre : identifiant unique du sous-genre (clé2)
Id_espèce : identifiant unique du espèce maître (clé1)
Id_sous-espèce : identifiant unique du sous-espèce (clé2)
Structure des tables à affiner suivant les informations obligatoires de
la table Animal.
Si [espèce] [sous-espèce] est lié à [genre] [sous-genre], alors il faut
ajouter aux table [espèce] [sous-espèce] les clés de [genre] [sous-genre].
De cette manière, ton formulaire de création d'animal, sera composé de
différentes listes déroulantes cohérentes entres elles.
Ensuite, les requêtes s'effectueront facilement car les relations seront
prédéfinies.
J'espère ne pas avoir été trop brouillon dans mes explications, et,
encore une fois, je n'essaie juste que de t'aider.
Bon courage,
Richard.
"moromain" <rm.acwed@gmail.com> a écrit dans le message de news:
d071a19d-8386-4f85-9098-93004cdf0489@f10g2000hsf.googlegroups.com...
Et pourquoi pas ?!!!!
Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal
un classement du type : [genre] [espèce].
Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous-
espèce]. Tous les niveaux ne sont pas renseignés.
Je n'ai pas voulu être désagréable, mais j'essaye de comprendre. Excuses-moi mais, dans ton cas, d'un point de vue analyse informatique (c'est mon métier), il ne s'agit pas de relation "père-fils" entre un animal et son [genre] [sous-genre] [espèce] [sous-espèce]. Il ne s'agit donc pas de nomenclature, à proprement parler. Je pense donc que tes tables devraient être construites de la manière suivante, ce qui résoudra ton problème par des requêtes :
Table_sous-espèce : Id_espèce : identifiant unique du espèce maître (clé1) Id_sous-espèce : identifiant unique du sous-espèce (clé2) Nom_sous-espèce
Table_animal : Id_animal : identifiant unique de l'animal Nom_animal Id_genre : identifiant unique du genre maître (clé1) Id_sous-genre : identifiant unique du sous-genre (clé2) Id_espèce : identifiant unique du espèce maître (clé1) Id_sous-espèce : identifiant unique du sous-espèce (clé2)
Structure des tables à affiner suivant les informations obligatoires de la table Animal.
Si [espèce] [sous-espèce] est lié à [genre] [sous-genre], alors il faut ajouter aux table [espèce] [sous-espèce] les clés de [genre] [sous-genre]. De cette manière, ton formulaire de création d'animal, sera composé de différentes listes déroulantes cohérentes entres elles. Ensuite, les requêtes s'effectueront facilement car les relations seront prédéfinies.
J'espère ne pas avoir été trop brouillon dans mes explications, et, encore une fois, je n'essaie juste que de t'aider. Bon courage, Richard.
"moromain" a écrit dans le message de news:
Et pourquoi pas ?!!!! Il s'agit d'une nomenclature naturaliste. On peut avoir pour un animal un classement du type : [genre] [espèce]. Pour un autre, on peut avoir : [genre] [sous-genre] [espèce] [sous- espèce]. Tous les niveaux ne sont pas renseignés.
Michel_D
Bonjour,
Théoriquement voila ta requête (enfin la modélisation) :
SELECT C2 AS Nv1, Null AS Nv2, Null AS Nv3, Null AS Nv4 FROM T WHERE (C3 Is Null) UNION SELECT N1.C2, N2.C2, Null, Null FROM T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) UNION SELECT N1.C2, Null, N3.C2, Null FROM T AS N3 INNER JOIN T AS N1 ON N3.C3=N1.C1 WHERE (N1.C3 Is Null) And (N3.C4=3) UNION SELECT N1.C2, N2.C2, N3.C2, Null FROM T AS N3 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N3.C3=N2.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3) UNION SELECT N1.C2, Null, Null, N4.C2 FROM T AS N4 INNER JOIN T AS N1 ON N4.C3=N1.C1 WHERE (N1.C3 Is Null) And (N4.C4=4) UNION SELECT N1.C2, N2.C2, Null, N4.C2 FROM T AS N4 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N4.C3=N2.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N4.C4=4) UNION SELECT N1.C2, Null, N3.C2, N4.C2 FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN T AS N1 ON N3.C3=N1.C1) ON N4.C3=N3.C1 WHERE (N1.C3 Is Null) And (N3.C4=3) And (N4.C4=4) UNION SELECT N1.C2, N2.C2, N3.C2, N4.C2 FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N3.C3=N2.C1) ON N4.C3=N3.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3) And (N4.C4=4);
"moromain" a écrit dans le message de news: Bonjour à tous,
Je relance un post (http://groups.google.fr/group/ microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/ bc179a9d0a0a3073?hl=fr&lnk=st&q=#) , suite à une modification de ma liste de base et suite à une amélioration que je recherche. J'ai une table avec plusieurs champs C1, C2, C3 : - C1 est l'iD de chaque enregistrement, - C2 contient le nom de l'enregistrement, - C3 renvoi à un iD, appelé "père". - C4 correspond au numéro de la colonne dans laquelle doit apparaitre le champs : dans ma nomenclature, certains niveaux peuvent être vides. Un exemple pour plus de clarté :
Qui se transformera en : 1__2____3____4 A A__AG A__AG_______AGY A__AG__AGH A__AK B B______BC B______BC___BCJ
J'ai essayé de transformer la requête proposée par Michel, sans succès.
Une idée de modification ?
Bonjour,
Théoriquement voila ta requête (enfin la modélisation) :
SELECT C2 AS Nv1, Null AS Nv2, Null AS Nv3, Null AS Nv4
FROM T
WHERE (C3 Is Null)
UNION SELECT N1.C2, N2.C2, Null, Null
FROM T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1
WHERE (N1.C3 Is Null) And (N2.C4=2)
UNION SELECT N1.C2, Null, N3.C2, Null
FROM T AS N3 INNER JOIN T AS N1 ON N3.C3=N1.C1
WHERE (N1.C3 Is Null) And (N3.C4=3)
UNION SELECT N1.C2, N2.C2, N3.C2, Null
FROM T AS N3 INNER JOIN (T AS N2 INNER JOIN T AS N1
ON N2.C3=N1.C1) ON N3.C3=N2.C1
WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3)
UNION SELECT N1.C2, Null, Null, N4.C2
FROM T AS N4 INNER JOIN T AS N1 ON N4.C3=N1.C1
WHERE (N1.C3 Is Null) And (N4.C4=4)
UNION SELECT N1.C2, N2.C2, Null, N4.C2
FROM T AS N4 INNER JOIN (T AS N2 INNER JOIN T AS N1
ON N2.C3=N1.C1) ON N4.C3=N2.C1
WHERE (N1.C3 Is Null) And (N2.C4=2) And (N4.C4=4)
UNION SELECT N1.C2, Null, N3.C2, N4.C2
FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN T AS N1
ON N3.C3=N1.C1) ON N4.C3=N3.C1
WHERE (N1.C3 Is Null) And (N3.C4=3) And (N4.C4=4)
UNION SELECT N1.C2, N2.C2, N3.C2, N4.C2
FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN
(T AS N2 INNER JOIN T AS N1
ON N2.C3=N1.C1) ON N3.C3=N2.C1) ON N4.C3=N3.C1
WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3) And (N4.C4=4);
"moromain" <rm.acwed@gmail.com> a écrit dans le message de news:60d5c73f-0c69-4536-ba61-dbffe7b3dc32@m34g2000hsf.googlegroups.com...
Bonjour à tous,
Je relance un post (http://groups.google.fr/group/
microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/
bc179a9d0a0a3073?hl=fr&lnk=st&q=#)
, suite à une modification de ma liste de base et suite à une
amélioration que je recherche.
J'ai une table avec plusieurs champs C1, C2, C3 :
- C1 est l'iD de chaque enregistrement,
- C2 contient le nom de l'enregistrement,
- C3 renvoi à un iD, appelé "père".
- C4 correspond au numéro de la colonne dans laquelle doit apparaitre
le champs : dans ma nomenclature, certains niveaux peuvent être vides.
Un exemple pour plus de clarté :
Théoriquement voila ta requête (enfin la modélisation) :
SELECT C2 AS Nv1, Null AS Nv2, Null AS Nv3, Null AS Nv4 FROM T WHERE (C3 Is Null) UNION SELECT N1.C2, N2.C2, Null, Null FROM T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) UNION SELECT N1.C2, Null, N3.C2, Null FROM T AS N3 INNER JOIN T AS N1 ON N3.C3=N1.C1 WHERE (N1.C3 Is Null) And (N3.C4=3) UNION SELECT N1.C2, N2.C2, N3.C2, Null FROM T AS N3 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N3.C3=N2.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3) UNION SELECT N1.C2, Null, Null, N4.C2 FROM T AS N4 INNER JOIN T AS N1 ON N4.C3=N1.C1 WHERE (N1.C3 Is Null) And (N4.C4=4) UNION SELECT N1.C2, N2.C2, Null, N4.C2 FROM T AS N4 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N4.C3=N2.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N4.C4=4) UNION SELECT N1.C2, Null, N3.C2, N4.C2 FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN T AS N1 ON N3.C3=N1.C1) ON N4.C3=N3.C1 WHERE (N1.C3 Is Null) And (N3.C4=3) And (N4.C4=4) UNION SELECT N1.C2, N2.C2, N3.C2, N4.C2 FROM T AS N4 INNER JOIN (T AS N3 INNER JOIN (T AS N2 INNER JOIN T AS N1 ON N2.C3=N1.C1) ON N3.C3=N2.C1) ON N4.C3=N3.C1 WHERE (N1.C3 Is Null) And (N2.C4=2) And (N3.C4=3) And (N4.C4=4);
"moromain" a écrit dans le message de news: Bonjour à tous,
Je relance un post (http://groups.google.fr/group/ microsoft.public.fr.access/browse_thread/thread/a7968bca94581f4/ bc179a9d0a0a3073?hl=fr&lnk=st&q=#) , suite à une modification de ma liste de base et suite à une amélioration que je recherche. J'ai une table avec plusieurs champs C1, C2, C3 : - C1 est l'iD de chaque enregistrement, - C2 contient le nom de l'enregistrement, - C3 renvoi à un iD, appelé "père". - C4 correspond au numéro de la colonne dans laquelle doit apparaitre le champs : dans ma nomenclature, certains niveaux peuvent être vides. Un exemple pour plus de clarté :
Qui se transformera en : 1__2____3____4 A A__AG A__AG_______AGY A__AG__AGH A__AK B B______BC B______BC___BCJ
J'ai essayé de transformer la requête proposée par Michel, sans succès.
Une idée de modification ?
moromain
Bonjour,
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
Bonjour,
J'avais un peu ça en tête mais en plus léger !
Si j'ai bien compris, il faut écrire une ligne de code pour chaque
combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position.
Donc 4 positions possibles = 8 séries de codes.
J'essaie de transformer une table qui contient 22 niveaux (22
positions possibles) ! Je prends ma calculette, et... aïe aïe aïe !
Trop de lignes de codes !
J'ai plus vite fait de créer une requête pour chaque niveau, puis de
les coller une à une avec des requêtes UNION, non ? C'est pas beau,
mais plus rapide.
Qu'en pensez-vous ?
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
Michel_D
Bonjour,
Le problème est plutot de savoir la finalitée de la chose, car il serait peut-être plus sage de suivre le conseil de Richard.
"moromain" a écrit dans le message de news: Bonjour,
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
Bonjour,
Le problème est plutot de savoir la finalitée de la chose, car il serait
peut-être plus sage de suivre le conseil de Richard.
"moromain" <rm.acwed@gmail.com> a écrit dans le message de news:bc42b61c-0552-4145-9366-b951b7d0e239@v46g2000hsv.googlegroups.com...
Bonjour,
J'avais un peu ça en tête mais en plus léger !
Si j'ai bien compris, il faut écrire une ligne de code pour chaque
combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position.
Donc 4 positions possibles = 8 séries de codes.
J'essaie de transformer une table qui contient 22 niveaux (22
positions possibles) ! Je prends ma calculette, et... aïe aïe aïe !
Trop de lignes de codes !
J'ai plus vite fait de créer une requête pour chaque niveau, puis de
les coller une à une avec des requêtes UNION, non ? C'est pas beau,
mais plus rapide.
Qu'en pensez-vous ?
Le problème est plutot de savoir la finalitée de la chose, car il serait peut-être plus sage de suivre le conseil de Richard.
"moromain" a écrit dans le message de news: Bonjour,
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
Richard_35
Bonjour Moromain et Michel_D,
Moromain, il est essentiel que ta base de données (liste des tables) soit bien définie et cohérente. Un table unique "simplifiée", ou qui te paraîtra comme telle, t'obligera à résoudre ces problèmes d'analyse par du code "complexe" et par des requêtes "alambiquées" ; le tout in-maintenable, le jour ou tu voudras modifier quelque chose... Alors qu'avec une base de données bien définie (clé, relations 1 pour N, etc...), le code "coule " tout seul... Et même, 90% du développement pourra s'effectuer à l'aide des assistants et macro, donc sans code. Loin de moi l'idée d'être arrogant, Moromain, mais c'est une règle de base : les tables doivent être nickel(les...) avant d'attaquer l'emploi des assistants et, à frotiori, l'écriture de code.
Bon courage, Richard.
"Michel_D" a écrit dans le message de news: fo73hr$1ki$
Bonjour,
Le problème est plutot de savoir la finalitée de la chose, car il serait peut-être plus sage de suivre le conseil de Richard.
"moromain" a écrit dans le message de news: Bonjour,
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
Bonjour Moromain et Michel_D,
Moromain, il est essentiel que ta base de données (liste des tables)
soit bien définie et cohérente.
Un table unique "simplifiée", ou qui te paraîtra comme telle, t'obligera
à résoudre ces problèmes d'analyse par du code "complexe" et par des
requêtes "alambiquées" ; le tout in-maintenable, le jour ou tu voudras
modifier quelque chose...
Alors qu'avec une base de données bien définie (clé, relations 1 pour N,
etc...), le code "coule " tout seul... Et même, 90% du développement pourra
s'effectuer à l'aide des assistants et macro, donc sans code.
Loin de moi l'idée d'être arrogant, Moromain, mais c'est une règle de
base : les tables doivent être nickel(les...) avant d'attaquer l'emploi des
assistants et, à frotiori, l'écriture de code.
Bon courage,
Richard.
"Michel_D" <michel.NOSPAM@orange-ft.com.invalid> a écrit dans le message de
news: fo73hr$1ki$1@news.rd.francetelecom.fr...
Bonjour,
Le problème est plutot de savoir la finalitée de la chose, car il serait
peut-être plus sage de suivre le conseil de Richard.
"moromain" <rm.acwed@gmail.com> a écrit dans le message de
news:bc42b61c-0552-4145-9366-b951b7d0e239@v46g2000hsv.googlegroups.com...
Bonjour,
J'avais un peu ça en tête mais en plus léger !
Si j'ai bien compris, il faut écrire une ligne de code pour chaque
combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position.
Donc 4 positions possibles = 8 séries de codes.
J'essaie de transformer une table qui contient 22 niveaux (22
positions possibles) ! Je prends ma calculette, et... aïe aïe aïe !
Trop de lignes de codes !
J'ai plus vite fait de créer une requête pour chaque niveau, puis de
les coller une à une avec des requêtes UNION, non ? C'est pas beau,
mais plus rapide.
Qu'en pensez-vous ?
Moromain, il est essentiel que ta base de données (liste des tables) soit bien définie et cohérente. Un table unique "simplifiée", ou qui te paraîtra comme telle, t'obligera à résoudre ces problèmes d'analyse par du code "complexe" et par des requêtes "alambiquées" ; le tout in-maintenable, le jour ou tu voudras modifier quelque chose... Alors qu'avec une base de données bien définie (clé, relations 1 pour N, etc...), le code "coule " tout seul... Et même, 90% du développement pourra s'effectuer à l'aide des assistants et macro, donc sans code. Loin de moi l'idée d'être arrogant, Moromain, mais c'est une règle de base : les tables doivent être nickel(les...) avant d'attaquer l'emploi des assistants et, à frotiori, l'écriture de code.
Bon courage, Richard.
"Michel_D" a écrit dans le message de news: fo73hr$1ki$
Bonjour,
Le problème est plutot de savoir la finalitée de la chose, car il serait peut-être plus sage de suivre le conseil de Richard.
"moromain" a écrit dans le message de news: Bonjour,
J'avais un peu ça en tête mais en plus léger ! Si j'ai bien compris, il faut écrire une ligne de code pour chaque combinaison possible : le Nx.Cy est à la 1ere, 2e, 3e ou 4e position. Donc 4 positions possibles = 8 séries de codes. J'essaie de transformer une table qui contient 22 niveaux (22 positions possibles) ! Je prends ma calculette, et... aïe aïe aïe ! Trop de lignes de codes ! J'ai plus vite fait de créer une requête pour chaque niveau, puis de les coller une à une avec des requêtes UNION, non ? C'est pas beau, mais plus rapide. Qu'en pensez-vous ?
