Object type ou relationnel

Bonjour,

je me pose une question concernant l'utilisation des TYPE AS OBJECT.

Cela reviens a faire du relationnel en quelque sorte. Je m'explique plutot de definir des relations entre differente table en utilisant des foreign key, on peut tres bien faire la même chose en utilisant des TYPE.

La question que je me pose est donc:

1)peut mettre des index sur des Object Type a l'interieur d'une table.

2)est ce que les preformane d'object TYPE imbriqué sont meilleur qu'un shema ralationnel normal (foreign key)

Merci pour l'aide.

PS= n'hésitez pas a me dire si je me suis trompé quelque part.

je crois que tu confonds relationnel et objet :?

Si tu pense que relationnel signifie la possibilité de « définir de relations dans différentes tables par des FK » alors tu devrais étudier la théorie du model relationnel. Cella te permettra de mieux comprendra déjà ta question.

posté par orafrance
"je crois que tu confonds relationnel et objet "

pour tant je ne voie pas de réelle difference entre mettre en relation des tables ou des object. la principe matriciel semble rester le même.

pour repondre a mnitu :
si la notion de clef secondaire t un fondement du relationnel. tu n'as surement pas travailler sur DL1 et la notion de pont entre de simple fichier indexe. Et puis je n'est pas dis que le relationnel n'etait que les clef secondaire.

Où tu veux en venir ? Oui tu peux faire des relations entre objet, mais tu ne pourras pas profiter du moteur relationnel du SGBD... pas de FK, DELETE CASCADE, index de jointure, etc... :?

Salut orafrance est merci pour la reponse.

dans le cas ou j'uiliserais les nested table et cette commande

"CREATE TABLE address_table OF cust_address_t"

Puisqu'il est possible d'utiliser les index sur les nested table. Est qu'il est possible d'utiliser les fonctions du moteur relationnel du SGBD ?

sutout les indexes de jointure et les cascade ?

merci d'avance.

par la même occasion si tu connais un bon document concernant les nested table. Je suis prenneur.

A+

un index sert à optimiser les accés disques... une nested table c'est un tableau en mémoire... j'vois pas bien pourquoi tu voudrais les indexer...

Tu compares une table (objet stocké) avec une nested table (tableau en mémoire)... j'vois pas bien ce que tu veux faire avec ça :?

Citation:

---

Envoyé par hterrolle

par la même occasion si tu connais un bon document concernant les nested table. Je suis prenneur.

---

la doc Oracle : http://www.oracle.com/pls/db102/homepage

merci encore orafrance,

je n'avais pas compris que les nested table etait des objects en memoire. Je pensais que c'etait juste une nouvelle methode (pour moi) de refenrencement des tables.

cela change tout alors.

re salut,

apparament je n'ais rien lu specifiant que les nested table sont argé en memoire. Cela ressemble a une table normal sinon que les rows sont considere comme des objects ?

Citation:

---

Envoyé par hterrolle

...
pour repondre a mnitu :
si la notion de clef secondaire t un fondement du relationnel.
...

---

Est-ce que tu peut le démontrer, prouver, expliquer ? En détail, STP ?

Citation:

---

...
tu n'as surement pas travailler sur DL1 et la notion de pont entre de simple fichier indexe.
...

---

Peut tu m'expliquer comment tu justifie cette affirmation, STP ?

Citation:

---

...
Et puis je n'est pas dis que le relationnel n'etait que les clef secondaire.

---

Peut tu donner une définition de la rélation, STP ?

Si non je trouve ton réponse envers moi assez agressif et non justifie. Et face à l'ignorance agressive je ne réponde pas.

Citation:

---

Envoyé par mnitu

Et face à l'ignorance agressive je ne réponde pas.

---

trop tard :mouarf:

Mais non, mais non, c'est jamais trop tard. Il peut se racheter encore.
On fait tous des erreurs (au moins nous deux, pour ne pas injurie les autres qui ne sont pas d'accord avec cette affirmation).

salut orafrance,

te serait il possible de m'expliquer dans quelle cas utiliser une nested table plutot qu'une table normal.

Quand est il des preformance des nested table pour des fichiers volumineux ?

merci

Pas facile de répondre à une telle question. une table imbriquée reste pertinente lorsqu'il s'agit de stocker plusieurs valeurs possibles dans une même colonne. Mais elle est un obstacle à la normalisation et reste plus compliquée à gérer qu'une relation simple de type FK.
Je me demande si ce concept n'a pas été introduit pour suivre la concurence ou simplement adhérer d'avantage aux normes... (comme les tables objet, d'ailleurs, que personne, ou presque, n'utilise :mouarf:)

Si vous voulez tout savoir la dessus, achetez le bouquin de Christian Soutou

je pense que ça facilite la vie pour le dév java... mais c'est pas super dans une normalisation merisienne :?

En tout cas, je le fuis comme la peste :mrgreen:

merci a vous deux,

Sympa pour la reference de bouquin SheikYerbouti. C'est exactement se qu'il me faut. C'est vraiment que les tables objects differe a la fois dans le mode d'utilisation que dans le mode de la conceptualisation.

Mais c'est vers là qu'il faudras se tourner taux ou tard.

merci encore

Citation:

---

Envoyé par SheikYerbouti

Pas facile de répondre à une telle question. une table imbriquée reste pertinente lorsqu'il s'agit de stocker plusieurs valeurs possibles dans une même colonne. Mais elle est un obstacle à la normalisation et reste plus compliquée à gérer qu'une relation simple de type FK.
Je me demande si ce concept n'a pas été introduit pour suivre la concurence ou simplement adhérer d'avantage aux normes... (comme les tables objet, d'ailleurs, que personne, ou presque, n'utilise :mouarf:)
...

---

Pourriez-vous expliquer en quoi il s'agit d'un obstacle à la normalisation?

Dans les bases des données SQL les relations sont les tables et non le FK. Du ce point de vue la question posé est en quoi une table (relation) habituelle diffère d'une table (relation) defini comme attribut d'une autre relation. Votre réponse suggère qu'il s'agit d'une construction artificielle non prévu dans le modelé relationnel ce qui n'est pas vrai (au moins d'après mon "ami" C. J. Date).

Formulé de cette manière trouvez vous plus facile de répondre à la question ?

Citation:

---

Orafrance
...mais c'est pas super dans une normalisation merisienne

---

Dans (SG)BDR, R c'est pour Relationnel et non pas Merisienne. :mouarf:

Un des buts de le normalisation est d'éviter la redondance d'information dans les tables. Maintenant, une table peut contenir une collection composée de types simples ou objets, eux même pouvant être composés de sous-type, etc...
Pour faire simple, une table peut contenir un objet contenant des miryades d'informations composites, ce qui ne va pas dans le sens de la normalisation.

c'est peut être un peut plus compliquer a gerer avec des object imbrique. Mais au niveau conceptualisation, cela permet d'eviter les redondances dans beaucoup de cas.

M'enfin c'est pas simple, là on est d'accord. Mais comme j'ai un outil maison pour faire se genre de shema ca m'arrnge beaucoup les tables orienté objet.