IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

postgre 10 -notion de clé étrangere


Sujet :

PostgreSQL

  1. #1
    Membre habitué Avatar de dedalios
    Homme Profil pro
    concepteur d'application
    Inscrit en
    Février 2008
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : concepteur d'application
    Secteur : Santé

    Informations forums :
    Inscription : Février 2008
    Messages : 492
    Points : 152
    Points
    152
    Par défaut postgre 10 -notion de clé étrangere
    Bonjour

    Concept de cle étranger

    voici la vision table tbr_0110 est lié à tbr_0120 par le champ Code_tbr_0110 .
    La table tbr_0110 et tbr_0110_a de légere différence sont les clé primaire
    Pour ces 2 tables les champs suivant sont fixes.
    Type_enr ='0110'
    Drapeau = 'C'

    Pour les 4 champ suivant la valeur est unique (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) raison de sa définition de cle primaire pour la table tbr_0110_a.


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
     
    CREATE TABLE tbr_0110 (
            Type_enr varchar(4) ,
            Drapeau varchar(1),
            Code_tbr_0110  varchar(10) NOT NULL PRIMARY KEY ,
            Date_debut   DATE,
            Date_fin DATE,
            Libelle varchar(50)       
            );
     
     CREATE TABLE TRB_GE_0120 (
                Type_enr varchar(4),
                Drapeau varchar(1),
                Code_tbr_0110  varchar(10),
                Code_tbr_0120 varchar(10),
                Date_debut  DATE,
                Date_fin DATE,
                Description varchar(250),
                Ordre_vente INTEGER,
                nb_de_valeur INTEGER,
                CONSTRAINT TRB_GE_0120_PK PRIMARY KEY (Code_tbr_0110 , Code_tbr_0120 , Date_debut ) ,
                FOREIGN KEY(Code_tbr_0110) REFERENCES tbr_0110 (Code_tbr_0110)
                 );
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    CREATE TABLE tbr_0110_a (
            Type_enr varchar(4) ,
            Drapeau varchar(1),
            Code_tbr_0110  varchar(10) ,
            Date_debut   DATE,
            Date_fin DATE,
            Libelle varchar(50),
    		CONSTRAINT tbr_0110_PK PRIMARY KEY (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) 
            );
     
    CREATE TABLE tbr_0120_a (
                Type_enr varchar(4),
                Drapeau varchar(1),
                Code_tbr_0110  varchar(10),
                Code_tbr_0120 varchar(10),
                Date_debut  DATE,
                Date_fin DATE,
                Description varchar(250),
                Ordre_vente INTEGER,
                nb_de_valeur INTEGER,
                CONSTRAINT tbr_0120_a_pk PRIMARY KEY (Type_enr , Drapeau ,Code_tbr_0110 , Code_tbr_0120 , Date_debut ) ,
                FOREIGN KEY(Code_tbr_0110) REFERENCES tbr_0110_a (Code_tbr_0110)
                 );

    mon problème est sur la définition FOREIGN KEY dans tbr_0120_a , la creation de la table tbr_0120_a.

    Le système refuse de définir la clé étrangere car il ne s'agit pas d'un clé primaire de la table tbr_0110_a.

    alors pourquoi ne pas utiliser les champs de la cle primaire de la table tbr_0110_a (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) et bien parce que le contenu des champs Date_debut et Date_fin sont des valeurs unique à chaque table .

    on peu ainsi avoir
    table tbr_0110_a
    Type_enr Drapeau Code_tbr_0110 Date_debut Date_fin Libelle
    '0110' 'c' 'TAX456' 01/01/2010 null valeur des codages TAX456
    '0110' 'c' 'XME16' 01/01/2015 null valeur des ecarts




    table tbr_0110_a
    Type_enr Drapeau Code_tbr_0110 Code_tbr_0120 Date_debut Date_fin Description Ordre_vente nb_de_valeur
    '0120' 'c' 'TAX456' 'Oker77' 01/02/2011 31/12/2013 Traitement des informations 1 22
    '0120' 'c' 'TAX456' 'OPER456' 01/01/2015 31/12/2017 Traitement des affectation 2 17
    '0120' 'c' 'XME16' 'Aw15' 01/01/2010 null Traitement operation complexe 1 33

    Quelle serait selon vous la FOREIGN KEY a creer pour tbr_0120_a ?

    Comment creer un lien entre ces 2 tables ?

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Votre modèle est complétement foireux. C'est la raison pour laquelle vous n'arrivez à rien. Commencez par un MCD au lieu de foncer sur le MPD et les CREATE TABLE. Expliquez nous clairement et de manière conceptuel ce que vous voulez faire avec des mot et non pas des codes... tbr_010, tbr_020 ne signifie rien. En matière de bases de données, les noms sont importants....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par dedalios Voir le message
    Concept de cle étranger
    La clef étrangère est, comme son nom l'indique, héritée d'une clef primaire issue d'une autre table
    Il convient donc de commencer par définir correctement la clef primaire dans la table en question et c'est loin d'être le cas ici

    Pour commencer, pourquoi mettre en table des valeurs constantes ?

    Citation Envoyé par dedalios Voir le message
    Pour ces 2 tables les champs suivant sont fixes.
    Type_enr ='0110'
    Drapeau = 'C'
    Si vraiment ces deux attributs ou colonnes (il n'y a pas de champ dans une table) ont une valeur constante et que ce sera le cas sur la durée de vie de la database, inutile de les stocker.

    De plus, un identifiant primaire doit être unique, stable et concis, or
    - vous avez choisi un identifiant primaire sur plusieurs colonnes : l'identifiant n'est pas concis
    - vous avez choisi un identifiant primaire qui utilise des colonnes (var)char : l'identifiant est potentiellement instable et qui plus est, sensible à la collation et encombrant

    Citation Envoyé par dedalios Voir le message
    Pour les 4 champ suivant la valeur est unique (Type_enr , Drapeau , Code_tbr_0110 , Date_debut) raison de sa définition de cle primaire pour la table tbr_0110_a.
    Ajoutez un identifiant technique de type integer et attribué par le SGBD ("generated by default as identity") qui garantira l'unicité, la concision et la performance de votre PK

  4. #4
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 814
    Points
    17 814
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    La clef étrangère est, comme son nom l'indique, héritée d'une clef primaire issue d'une autre table
    C'est souvent un peu oublié, mais une contrainte d'unicité suffit à être la référence d'une clef étrangère.

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Waldar Voir le message
    C'est souvent un peu oublié, mais une contrainte d'unicité suffit à être la référence d'une clef étrangère.
    Yes mais l'idée ici c'est qu'il faut corriger le problème à sa source

  6. #6
    Membre habitué Avatar de dedalios
    Homme Profil pro
    concepteur d'application
    Inscrit en
    Février 2008
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : concepteur d'application
    Secteur : Santé

    Informations forums :
    Inscription : Février 2008
    Messages : 492
    Points : 152
    Points
    152
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Votre modèle est complétement foireux. C'est la raison pour laquelle vous n'arrivez à rien. Commencez par un MCD au lieu de foncer sur le MPD et les CREATE TABLE. Expliquez nous clairement et de manière conceptuel ce que vous voulez faire avec des mot et non pas des codes... tbr_010, tbr_020 ne signifie rien. En matière de bases de données, les noms sont importants....

    A +
    Les termes utilisés sont malheureusement volontairement des codes pour des questions de non divulgation . Et je ne dispose ni du MPD ni du MCD mais des données brutes hors ce que je vous présente c'est la forme de ces donnée brutes .

    Il faut que j'en construise le modele cela afin de le comparer a un second modele pour lequelle je ne dispose aussi que des données.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    Pour ces 2 tables les champs suivant sont fixes.
    Type_enr ='0110'
    Drapeau = 'C'
    Ceci n'est pas totalement vrai ; ce projet oui sur les donnée fournies seront fixe et contenu das les fichiers a convertir (donc peut être effectivement a supprimer du MPD / MCD
    Pour ces 2 tables les champs suivant sont fixes.
    si Type_enr ='0110' est fixe , Drapeau = a plusieurs valeurs possible .

  7. #7
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 966
    Points : 30 778
    Points
    30 778
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    dedalios, vos structures de tables sont à aménager. La table tbr_0110_a possède une clé candidate qui intrigue :

    {Type_enr , Drapeau ,Code_tbr_0110 , Date_debut}

    Pour aller dans le sens des sages, escartefigue et Waldar, et travailler dans les règles de l’art, vous devriez ajouter un attribut tbr_110_Id, de type INTEGER (ou SERIAL de préférence, mais peu importe) sans aucune signification et invariant. Cet attribut serait utilisé pour une clé supplémentaire, alternative (alternate key) :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    CREATE TABLE tbr_0110_a 
    (
            tbr_110_Id integer,
            Type_enr varchar(4) ,
            Drapeau varchar(1),
            Code_tbr_0110  varchar(10) ,
            Date_debut   DATE,
            Date_fin DATE,
            Libelle varchar(50),
        CONSTRAINT tbr_0110_PK PRIMARY KEY (Type_enr , Drapeau , Code_tbr_0110 , Date_debut), 
        CONSTRAINT tbr_0110_AK UNIQUE (tbr_110_Id) 
    ) ;

    Le mieux serait de permuter les rôles des deux clés tbr_0110_PK et tbr_0110_AK, mais dans un 1er temps on peut rester en l’état.

    Définissez le même attribut tbr_110_Id dans l’autre table, et c’est lui qui servira pour la clé étrangère ; vous lui définissez également un attribut, tbr_120_Id, pour une clé supplémentaire {tbr_120_Id}, laquelle a tout intérêt à devenir clé primaire, tandis que l’autre clé (actuellement primaire) devient alternative : sitôt dit, sitôt fait :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
    CREATE TABLE tbr_0120_a 
    (
                tbr_110_Id integer,
                tbr_120_Id integer,
                Type_enr varchar(4),
                Drapeau varchar(1),
                Code_tbr_0110  varchar(10),      -- devrait disparaître !
                Code_tbr_0120 varchar(10),
                Date_debut  DATE,
                Date_fin DATE,
                Description varchar(250),
                Ordre_vente INTEGER,
                nb_de_valeur INTEGER,
            CONSTRAINT tbr_0120_a_PK PRIMARY KEY  (tbr_120_Id), 
            CONSTRAINT tbr_0120_a_AK UNIQUE (Type_enr , Drapeau ,Code_tbr_0110 , Code_tbr_0120 , Date_debut ) ,
            FOREIGN KEY(tbr_110_Id) REFERENCES tbr_0110_a (tbr_110_Id)
                 );

    Eliminez de tbr_0120_a les attributs que l’on sait retrouver par jointure des deux tables (et définissez une vue de jointure au besoin). Le ménage a une incidence sur tbr_0120_a_AK (disparition par exemple de Code_tbr_0110, au bénéfice de tbr_120_Id) mais cette « clé » à 5 attributs vérifie-t-elle bien l’irréductibilité des clés candidates ? Seules les règles de gestion des données permettent de le savoir, car elles sont notamment utilisées pour constituer l’ensemble des dépendances fonctionnelles sources des clés des tables.

    Tout comme escartefigue et Waldar, je ne prétends pas résoudre votre problème précis, on n’en sait pas assez quant aux règles de gestion des données (données primitives, données dérivables, pertinence des clés), mais au moins vous donner une idée des structures vers lesquelles devraient rendre vos tables.

    Tant qu’à faire, ajoutez « NOT NULL » pour chaque attribut de chaque table. Méditez aussi ce qu’a écrit Yves Tabourier au sujet des identifiants significatifs (voyez ici).

    Une 1re pour moi : le VARCHAR(1)...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  8. #8
    Membre habitué Avatar de dedalios
    Homme Profil pro
    concepteur d'application
    Inscrit en
    Février 2008
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : concepteur d'application
    Secteur : Santé

    Informations forums :
    Inscription : Février 2008
    Messages : 492
    Points : 152
    Points
    152
    Par défaut Cle primaire
    Effectivement créer des clés primaires automatiques est une solution interressante. Le problème par contre est de conservé la clé primaire pour injecté les donnée dans la table suivante , est accéssoirement faire de même pour 4 tables lié est le reste mais effectivement je ne vois pas d'autre solution.


    le VARCHAR(1) est simplement du a une transformation d'un type TEXT(1) TEXT(25)....etc.

    Utiliser une vue pour éliminer de tbr_0120_a les attributs présent dans tbr_0110. Effectivement c'est la solution mais je n'irais pas jusque la, le but n'est pas de réellement construire une base propre mais un processus de comparaison.


    Plus qu'a modifier les programmes d'alimentation
    merci

  9. #9
    Membre habitué Avatar de dedalios
    Homme Profil pro
    concepteur d'application
    Inscrit en
    Février 2008
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : concepteur d'application
    Secteur : Santé

    Informations forums :
    Inscription : Février 2008
    Messages : 492
    Points : 152
    Points
    152
    Par défaut SERIAL de préférence
    Create table avec une clé primaire sur une colonne de type serial, ok, mais comment récupérer l'identifiant unique après avoir effectué une insertion en table, car de fait le champ n'est pas saisi à l'insertion...

  10. #10
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 631
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 631
    Points : 30 865
    Points
    30 865
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par dedalios Voir le message
    Create table avec une clé primaire sur une colonne de type serial, ok, mais comment récupérer l'identifiant unique après avoir effectué une insertion en table, car de fait le champ n'est pas saisi à l'insertion...
    Bonjour

    Tu peux demander un insert into table values (..., ...) returning xxx ("xxx" étant le nom de ta colonne serial). La valeur du serial te sera donc retournée.

    Moi, personnellement, je ne passe pas par un serial mais par une sequence créée manuellement (create sequence "seq_toto" etc etc etc). Ensuite, j'affecte cette sequence à la colonne que je veux mettre en serial (create table "toto" ("id_toto" integer not null default nextval('"seq_toto"')) puis alter sequence "seq_toto" owned by "toto."."id_toto" (cette dernière n'est pas primordiale mais je trouve ça plus propre)).
    A la base ça revient au même (la colonne récupèrera la valeur de la séquence lors de l'insert tandis que la séquence s'incrémentera). Mais ça m'offre des possibilités en plus. Comme par exemple demander un select currval('"seq_toto"') ce qui me donne alors la valeur courante (donc la dernière valeur) de ma séquence.

    A partir de là, ce que je fais moi (mais en prog donc à partir d'un langage qui va interfacer Postgres): je demande d'abord un select nextval('"seq_toto"'). Ca me donne un n° utilisable et unique tandis que la sequence s'incrémente pour un autre insert ultérieur. Ensuite, j'intègre ce n° dans mon insert. Ben oui, ce n'est pas parce que le champ n'est pas à saisir qu'on n'a pas le droit de quand-même le saisir. Et donc c'est comme si j'avais eu un serial sauf que comme c'est moi qui l'ai d'abord manuellement demandé, je l'ai toujours en main et je peux ensuite m'en resservir (c'est surtout quand j'insère dans diverses tables liées entre elles)...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  11. #11
    Membre habitué Avatar de dedalios
    Homme Profil pro
    concepteur d'application
    Inscrit en
    Février 2008
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Indre et Loire (Centre)

    Informations professionnelles :
    Activité : concepteur d'application
    Secteur : Santé

    Informations forums :
    Inscription : Février 2008
    Messages : 492
    Points : 152
    Points
    152
    Par défaut Create séquence
    Create séquence similaire à Oracle donc.

    OK

    Bon ce qui veux dire que les insert sont à réaliser un enregistrement par un enregistrement.
    Qu’il n'est pas possible de réalisé x insert si l'on a besoin de l'information de ce champ comme foreign key pour la table ou est la susdite foreign key. je vais donc pose mon schéma plus global.


    alter sequence "seq_toto" owned by "toto."."id_toto" cette partie est plus nébuleuse.. pourquoi modifier les droits sur la séquence??

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par dedalios Voir le message
    Create séquence similaire à Oracle donc.

    OK

    Bon ce qui veux dire que les insert sont à réaliser un enregistrement par un enregistrement.
    Rien ne vous empêche de générer plusieurs valeurs de clef en une seule instruction, mais la difficulté est de savoir à quelle ligne sera attribuée la clef n°1 et ainsi de suite.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Class/PHP/Postgres] Problème de modélisation...
    Par k-reen dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 27/02/2003, 09h49
  2. Notion d'algorithme
    Par gtr dans le forum Algorithmes et structures de données
    Réponses: 3
    Dernier message: 10/12/2002, 12h46
  3. pk passer de mysql à postgre
    Par pioums dans le forum Autres SGBD
    Réponses: 2
    Dernier message: 03/10/2002, 11h31
  4. [Kylix] Requetes Kylix pour postgres
    Par Miltown dans le forum EDI
    Réponses: 1
    Dernier message: 29/05/2002, 21h22
  5. [Kylix] Kylix - Postgres
    Par Miltown dans le forum EDI
    Réponses: 1
    Dernier message: 29/05/2002, 21h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo