Non ce n'est pas un problème de logique, c'est simplement une solution de
FileMaker de gérer du relationnel n à n sans créer de table intermédiaire.
Mais c'est vrai, que cette solution offerte par FileMaker n'est pas
réellement aux normes des BDD mais permettait un gain de temps énorme en
temps de développement, surtout lorsque FileMaker était limité à 50 Fichiers
(donc tables).
Par contre, il est vrai que l'on peut faire un champs identique avec toutes
les bases de données, mais il faut faire une boucle pour avoir l'ensemble
des enregistrements liées ce qui n'est pas très sympa au niveau du
développement et pas aux "Normes" des BDD.
Mais avec FileMaker, le lien se fait tout seul avec tout les enregistrements
liés sans être obligé de faire une table intermédiaire, ni une boucle et en
une seule commande!!. Et pour les problèmes d'incompatibilité, on se trouve
dans la même situation que les autres bases de données si l'on ne fait pas
les contrôles.
Maintenant, il est vrai, qu'avec les dernière versions de FileMaker, comme
on n'est plus limité en nombre de table, il vaut peut être mieux abandonner
cette "astuce" afin de gérer des tables intermédiaires et être compatible
avec les autres BDD.
Snif...
Jean-Claude.
Le 22/12/06 0:06, « Michel LO » <michel dot lo at albireo dot biz> a écrit :
> Ce que vous dites me semble très bizarre, parce que le problème n à n
> n'est pas un problème de structure de base, mais un problème de logique.
>
> Si vous faites un champ idplan avec les id de tous les plans du
> produit, vous n'êtes plus dans une base normée te stable, mais vous
> gérez vous même, et on peut le faire alors dans n'importe quelle
> base. Il suffit de faire alors un select ou on passe dans l'autre
> sens en vérifiant qu'un idplan donné donne tous les enregistrements
> des produits où il y a le numéro dans le champ idplan "multiple".
>
> Mais e n'est vraiment pas bon, en FileMaker non plus d'ailleurs,
> parce que en fait, on gère à la main l'ensemble de tous les plans
> dans un sens et dans l'autre avec des risques graves d'icompatibilité
> (comme par exemple de rajouter un idplan qui n'existe pas dans un
> produit).
>
> Il FAUT faire un table intermédiaire pour rester dans une base
> normalisée, et c'est parce que File Maker ne sait pas créer une table
> intermédiaire du fait de ses limitations de non chainage (un lien ne
> se fait qu'entre deux tables) qu'il a fallu demander à l'utilisateur
> de le faire à la place du sgbd.
>
> Cela dit, la table intermédiaire est vachement simple : il s'agit
> d'une table qui contient des enregistrements de 2 champs : idplan et
> idprod.
> Et au lieu d'avoir dans la table produit un champ qu'on doit se gérer
> à la main pour ajouter ou enlever des plans, on a une série de petits
> enregistrements où il y a ou non une relation dans un sens et dans
> l'autre entre le produit et le plan s'il y a un champ avec le idplan
> et le idprod en question.
>
> Et ça, ce n'est pas chiant, c'est la seule façon de faire du
> normalisé et stable sans avoir rien à gérer à la main.
>
>
>
> Michel Lo
> BELT
> 45, rue Aristide Briand
> 92300 LEVALLOIS-PERRET
>
>
> Le 21 déc. 06 à 22:17, Youri a écrit :
>
>>
>> Salut Jean-Claude,
>>
>>
>> Damn', c'était trop beau de pouvoir espérer ;-)
>>
>> C'est en effet une fonctionnalité très sympa dont il est difficile
>> de se passer lorsqu'on y a gouté.
>>
>> Merci,
>>
>>
>> A+
>>
>> Youri
>>
>>
>>
>> Jean-Claude SERRANO wrote:
>>> Bonjour,
>>> Contrairement à FileMaker, RealBasic est une Base de Données ne
>>> permettant
>>> pas d'effectuer cette astuce que l'on utilise dans FileMaker et qui
>>> permettait de faire du relationnel (n,n) sans créer de table
>>> intermédiaire.
>>> Avec Real Basic, comme avec les autres bases de données
>>> relationnelles ont
>>> est obligé de créer une table intermédiaire :
>>> TableProduitsPlans
>>> IDProduit
>>> IDPlan
>>> Jusqu'a présent avec l'ensemble des BDD que j'ai utilisé, seul
>>> FileMaker
>>> permettait ce type de relation sans créer de table intermédiaire.
>>> @+
>>> Jean-Claude
>>> Le 20/12/06 22:37, « Youri » <lystes at free dot fr> a écrit :
>>>> Bonsoir,
>>>>
>>>>
>>>> Une technique courante que j'ai pris pour habitude d'utiliser dans
>>>> FileMaker lors de la création d'un "lien" de (1 à n) est de faire la
>>>> chose suivante :
>>>>
>>>> TablePRODUITS
>>>> IDProduit
>>>> NomProduit
>>>> idplan
>>>>
>>>>
>>>> TablePLANS
>>>> IDPlan
>>>> Reference
>>>> IndicePlan
>>>>
>>>> Pour 1 Produit A je peux avoir plusieurs Plans dans la
>>>> TablePLANS. Je
>>>> met donc les différentes IDPlan dans la rubrique
>>>> TablePRODUITS.idplan en
>>>> les séparant par un retour chariot.
>>>>
>>>> Quelle est la technique permettant de réaliser la même chose dans
>>>> RBSQL?
>>>> Faut-il passer par une table intermédiaire?
>>>>
>>>> Merci par avance,
>>>>
>>>>
>>>> A+
>>>>
>>>> Youri
>>>>
>
>
|