j'ai un petit problème de structure pour une bd sur les vins, c'est ma
table appellations.
Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec
seulement des régions et des appellations, j'avait donc deux tables :
t_appellations_alt et t_regions_reg
avec l'id de t_regions_reg dans t_appellations_alt.
Bon, maintenant la tendance est à classifier en région et sous-région et
dans certains pays, comme l'australie, il y a, avant la région, la zone,
la profondeur de l'arborescence est plus grande.
Peut-on gérer facilement ce genre de situation avec sql ?
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
Ph. B.
Yvon Thoraval a écrit:
j'ai un petit problème de structure pour une bd sur les vins, c'est ma table appellations.
Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec seulement des régions et des appellations, j'avait donc deux tables :
t_appellations_alt et t_regions_reg avec l'id de t_regions_reg dans t_appellations_alt.
Bon, maintenant la tendance est à classifier en région et sous-région et dans certains pays, comme l'australie, il y a, avant la région, la zone, la profondeur de l'arborescence est plus grande.
Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop rigide
2°) Tu géres cela de manière récursive avec une table de localisations, mais les requêtes d'interrogation vont vite devenir inexploitables en terme de temps d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Bonne lecture ! ;-)
-- Philippe.
Yvon Thoraval a écrit:
j'ai un petit problème de structure pour une bd sur les vins, c'est ma
table appellations.
Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec
seulement des régions et des appellations, j'avait donc deux tables :
t_appellations_alt et t_regions_reg
avec l'id de t_regions_reg dans t_appellations_alt.
Bon, maintenant la tendance est à classifier en région et sous-région et
dans certains pays, comme l'australie, il y a, avant la région, la zone,
la profondeur de l'arborescence est plus grande.
Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en
conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop rigide
2°) Tu géres cela de manière récursive avec une table de localisations, mais les
requêtes d'interrogation vont vite devenir inexploitables en terme de temps
d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table
et les requêtes restent très performantes !
Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé
tout cette mécanique sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
j'ai un petit problème de structure pour une bd sur les vins, c'est ma table appellations.
Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec seulement des régions et des appellations, j'avait donc deux tables :
t_appellations_alt et t_regions_reg avec l'id de t_regions_reg dans t_appellations_alt.
Bon, maintenant la tendance est à classifier en région et sous-région et dans certains pays, comme l'australie, il y a, avant la région, la zone, la profondeur de l'arborescence est plus grande.
Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop rigide
2°) Tu géres cela de manière récursive avec une table de localisations, mais les requêtes d'interrogation vont vite devenir inexploitables en terme de temps d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Bonne lecture ! ;-)
-- Philippe.
yvon.thoravalNO-SPAM
Ph. B. wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Ouais !!! Merci beaucoup, c'est exactement ce qu'il me fallait... -- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table et les requêtes restent très performantes ! Maintenant, je laisse la
parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique
sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
Ouais !!! Merci beaucoup, c'est exactement ce qu'il me fallait... -- yt
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Ouais !!! Merci beaucoup, c'est exactement ce qu'il me fallait... -- yt
Tom
Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
"Ph. B." a écrit dans le message de news:41582a0b$0$2257$
Yvon Thoraval a écrit:
> j'ai un petit problème de structure pour une bd sur les vins, c'est ma > table appellations. > > Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec > seulement des régions et des appellations, j'avait donc deux tables : > > t_appellations_alt et t_regions_reg > avec l'id de t_regions_reg dans t_appellations_alt. > > Bon, maintenant la tendance est à classifier en région et sous-région et > dans certains pays, comme l'australie, il y a, avant la région, la zone, > la profondeur de l'arborescence est plus grande. > > Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop
rigide
2°) Tu géres cela de manière récursive avec une table de localisations,
mais les
requêtes d'interrogation vont vite devenir inexploitables en terme de
temps
d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table
et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Bonne lecture ! ;-)
-- Philippe.
Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
"Ph. B." <philippe.boucault@voila_N_O_S_P_A_M_.fr> a écrit dans le message
de news:41582a0b$0$2257$626a14ce@news.free.fr...
Yvon Thoraval a écrit:
> j'ai un petit problème de structure pour une bd sur les vins, c'est ma
> table appellations.
>
> Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec
> seulement des régions et des appellations, j'avait donc deux tables :
>
> t_appellations_alt et t_regions_reg
> avec l'id de t_regions_reg dans t_appellations_alt.
>
> Bon, maintenant la tendance est à classifier en région et sous-région et
> dans certains pays, comme l'australie, il y a, avant la région, la zone,
> la profondeur de l'arborescence est plus grande.
>
> Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en
conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop
rigide
2°) Tu géres cela de manière récursive avec une table de localisations,
mais les
requêtes d'interrogation vont vite devenir inexploitables en terme de
temps
d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table
et les requêtes restent très performantes !
Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
"Ph. B." a écrit dans le message de news:41582a0b$0$2257$
Yvon Thoraval a écrit:
> j'ai un petit problème de structure pour une bd sur les vins, c'est ma > table appellations. > > Jusqu'ici je n'avais géré qu'un "petit" pays, la france ))), avec > seulement des régions et des appellations, j'avait donc deux tables : > > t_appellations_alt et t_regions_reg > avec l'id de t_regions_reg dans t_appellations_alt. > > Bon, maintenant la tendance est à classifier en région et sous-région et > dans certains pays, comme l'australie, il y a, avant la région, la zone, > la profondeur de l'arborescence est plus grande. > > Peut-on gérer facilement ce genre de situation avec sql ?
Bonjour,
Tu as 3 possibilités, mais tu peux oublier les 2 premières ! ;-)
1°) Tu connais le nb de classes possibles et tu définis tes tables en conséquence (1 par classe), mais cela devient lourd à gérer et c'est trop
rigide
2°) Tu géres cela de manière récursive avec une table de localisations,
mais les
requêtes d'interrogation vont vite devenir inexploitables en terme de
temps
d'exécution
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table
et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a
détaillé
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Bonne lecture ! ;-)
-- Philippe.
yvon.thoravalNO-SPAM
Tom wrote:
> tout cette mécanique sur son site à l'endroit suivant: > http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table d'appellations, les feuilles sont les appellations et les noeuds pays, zone, région, sous-région l'arborescence des noeuds étant variable d'un pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus facile.
il reste que dans le mode de représentation (java-swing) je dois mettre au point un tree-table qui aurait pour racine "terre" ))) -- yt
Tom <TomTom@badaboum.com> wrote:
> tout cette mécanique sur son site à l'endroit suivant:
> http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table
d'appellations, les feuilles sont les appellations et les noeuds pays,
zone, région, sous-région l'arborescence des noeuds étant variable d'un
pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus
facile.
il reste que dans le mode de représentation (java-swing) je dois mettre
au point un tree-table qui aurait pour racine "terre" )))
--
yt
> tout cette mécanique sur son site à l'endroit suivant: > http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table d'appellations, les feuilles sont les appellations et les noeuds pays, zone, région, sous-région l'arborescence des noeuds étant variable d'un pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus facile.
il reste que dans le mode de représentation (java-swing) je dois mettre au point un tree-table qui aurait pour racine "terre" ))) -- yt
yvon.thoravalNO-SPAM
Ph. B. wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table et les requêtes restent très performantes ! Maintenant, je laisse la
parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique
sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
Ph. B.
Yvon Thoraval wrote:
Ph. B. wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
Je ne crois pas...
Demandes à Frédéric : mailto:
-- Philippe.
Yvon Thoraval wrote:
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une
table et les requêtes restent très performantes ! Maintenant, je laisse la
parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique
sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
Je ne crois pas...
Demandes à Frédéric : mailto:brouardf@club-internet.fr
3°) Tu passes à une gestion intervallaire de ta hiérarchie, tu n'as qu'une table et les requêtes restent très performantes ! Maintenant, je laisse la parole et la place à Frédéric Brouard qui a détaillé tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
est-ce que cette page a été traduite en anglais ??? -- yt
Je ne crois pas...
Demandes à Frédéric : mailto:
-- Philippe.
Ph. B.
Yvon Thoraval wrote:
Tom wrote:
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table d'appellations, les feuilles sont les appellations et les noeuds pays, zone, région, sous-région l'arborescence des noeuds étant variable d'un pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus facile.
Une table de ce type par exemple:
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
il reste que dans le mode de représentation (java-swing) je dois mettre au point un tree-table qui aurait pour racine "terre" )))
tout cette mécanique sur son site à l'endroit suivant:
http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table
d'appellations, les feuilles sont les appellations et les noeuds pays,
zone, région, sous-région l'arborescence des noeuds étant variable d'un
pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus
facile.
Une table de ce type par exemple:
Appellation(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
APP_LIBELLE VARCHAR(64) NOT NULL,
APP_TYPE VARCHAR(32) NOT NULL
)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence
indiquant les types de localisation...
il reste que dans le mode de représentation (java-swing) je dois mettre
au point un tree-table qui aurait pour racine "terre" )))
tout cette mécanique sur son site à l'endroit suivant: http://sqlpro.developpez.com/Tree/SQL_tree.html
Merci pour ce lien fort interessant !
perso, je pense utiliser une méthode mixte, normalement dans ma table d'appellations, les feuilles sont les appellations et les noeuds pays, zone, région, sous-région l'arborescence des noeuds étant variable d'un pays à l'autre voire même dans le temps...
j'aurai donc :
un sql tree en représentation intervallaire ;
une table standard pour les appellations
je pense qu'ainsi l'insertion d'une nouvelle feuille est nettement plus facile.
Une table de ce type par exemple:
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
il reste que dans le mode de représentation (java-swing) je dois mettre au point un tree-table qui aurait pour racine "terre" )))
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet d'interdire plus d'une area de même nom pour un parent donné (unique (wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le niveau, je vai pouvoir écrire des classes java pour cela (insert, delete...) et les "storer" dans la database car j'utilise une bd java (Hypersonix SQL) qui me permet de faire un alias d'une classe java très facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
-- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
Une table de ce type par exemple:
Appellation(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
APP_LIBELLE VARCHAR(64) NOT NULL,
APP_TYPE VARCHAR(32) NOT NULL
)
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet
d'interdire plus d'une area de même nom pour un parent donné (unique
(wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence
indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de
respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le
niveau, je vai pouvoir écrire des classes java pour cela (insert,
delete...) et les "storer" dans la database car j'utilise une bd java
(Hypersonix SQL) qui me permet de faire un alias d'une classe java très
facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation
intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet d'interdire plus d'une area de même nom pour un parent donné (unique (wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le niveau, je vai pouvoir écrire des classes java pour cela (insert, delete...) et les "storer" dans la database car j'utilise une bd java (Hypersonix SQL) qui me permet de faire un alias d'une classe java très facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
-- yt
Ph. B.
Yvon Thoraval a écrit:
Ph. B. wrote:
Une table de ce type par exemple:
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet d'interdire plus d'une area de même nom pour un parent donné (unique (wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le niveau, je vai pouvoir écrire des classes java pour cela (insert, delete...) et les "storer" dans la database car j'utilise une bd java (Hypersonix SQL) qui me permet de faire un alias d'une classe java très facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des procédures stockées pour gérer les insertions, suppressions et déplacements d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
-- Philippe.
Yvon Thoraval a écrit:
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
Une table de ce type par exemple:
Appellation(
APP_ID INTEGER IDENTITY (1, 1) NOT NULL,
APP_BG INTEGER NOT NULL,
APP_BD INTEGER NOT NULL,
APP_NIVEAU INTEGER NOT NULL,
APP_LIBELLE VARCHAR(64) NOT NULL,
APP_TYPE VARCHAR(32) NOT NULL
)
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet
d'interdire plus d'une area de même nom pour un parent donné (unique
(wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence
indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de
respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le
niveau, je vai pouvoir écrire des classes java pour cela (insert,
delete...) et les "storer" dans la database car j'utilise une bd java
(Hypersonix SQL) qui me permet de faire un alias d'une classe java très
facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation
intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des
procédures stockées pour gérer les insertions, suppressions et déplacements
d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
Appellation( APP_ID INTEGER IDENTITY (1, 1) NOT NULL, APP_BG INTEGER NOT NULL, APP_BD INTEGER NOT NULL, APP_NIVEAU INTEGER NOT NULL, APP_LIBELLE VARCHAR(64) NOT NULL, APP_TYPE VARCHAR(32) NOT NULL )
j'ai mis un "wma_pid" qui est le "wwa_id" du parent, ça me permet d'interdire plus d'une area de même nom pour un parent donné (unique (wma_pid, wwa_desc))
(gtyp_id = ground type id, wcol_id = wine color id)
APP_TYPE peut être remplacé par une clé étrangère vers une table de référence indiquant les types de localisation...
Oui, très bonne idée, j'ai oublié cela, tant qu'à faire, ça permet de respecter le vocabulaire local...
Je trouve d'ailleurs que l'insertion se fait très facilement avec le niveau, je vai pouvoir écrire des classes java pour cela (insert, delete...) et les "storer" dans la database car j'utilise une bd java (Hypersonix SQL) qui me permet de faire un alias d'une classe java très facilement :
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt";
puis après l'utiliser dans un select par ex :
SELECT SQRT(A) , B FROM MYTABLE;
Donc, en fait, pour moi, l'utilisation de la représentation intervallaire sera complétement "transparente"...
Je dois dire que je trouve « géniale » cette représentation...
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des procédures stockées pour gérer les insertions, suppressions et déplacements d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
-- Philippe.
yvon.thoravalNO-SPAM
Ph. B. wrote:
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des procédures stockées pour gérer les insertions, suppressions et déplacements d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
oui, oui, j'ai vu, merci, mon cas est + simple que ce qu'il donne car j'utilise niveau...
en tk, c'est super-chouette cette représentation... -- yt
Ph. B. <philippe.boucault@voila_N_O_S_P_A_M_.fr> wrote:
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des
procédures stockées pour gérer les insertions, suppressions et déplacements
d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
oui, oui, j'ai vu, merci, mon cas est + simple que ce qu'il donne car
j'utilise niveau...
en tk, c'est super-chouette cette représentation...
--
yt
Pour rappel car tu as du le voir, tu as sur le site de Frédéric le code des procédures stockées pour gérer les insertions, suppressions et déplacements d'éléments ou de branches, que tu peux adapter à tes besoins... ;-)
oui, oui, j'ai vu, merci, mon cas est + simple que ce qu'il donne car j'utilise niveau...
en tk, c'est super-chouette cette représentation... -- yt
