SGBD Orienté Objet [Résolu]

[paonus]

s'il vous plait est ce que SQL Server est il un SGBD orienté objet ou non, si c'est possible quels sont tout les SGBD OO
merci d'avance

[ylarvor]

sql serveur n'est pas oriente objet. c'est un sgbd relationnel.

[SQLpro]

Je modérerais cela en disant que c'est possible en utilisant les types CLR !

En effet à l'aide de SQL CLR on peut créer ses types e données soit même et donc faire des tableaux, des arbres, des graphes, des objets quelconques. Il suffit de les interfacer avec Transact SQL.

A +

[omar.merroun]

c'est vrai qu'à partir de SQL SERVER 2005 on peut définir des classes (UDT) pour construire des objets.
là question que je me pose maintenant , est qu'est ce qu'il manque à SQL SERVER 2005 --> 2008 R2 pour qu'il deviennen un SGBD OO

[ylarvor]

La vitesse. Un SGBD objet se doit d'être plus rapide qu'un SGBD relationnel en ce qui concerne l'accès à un objet. Or Le CLR, proposait par SQL Pro, permet en effet de simuler le fonctionnement objet mais avec une vitesse moindre. Enfin, c'est mon avis!

[Ptit_Dje]

Une petite touche d'humour:
http://www.sqlservercentral.com/arti...terials/69043/

[ylarvor]

Marrant.

Le dernier programmez contient un article, disponible gratuitement sur le site de l'éditeur, qui présente l'objet et le relationnel.
Il précise que ce sont les fonctionnalités XML qui permettent d'émuler le fonctionnement d'une base objet.

Bonne année à vous.

[omar.merroun]

Envoyé par ylarvor

La vitesse. Un SGBD objet se doit d'être plus rapide qu'un SGBD relationnel en ce qui concerne l'accès à un objet. Or Le CLR, proposait par SQL Pro, permet en effet de simuler le fonctionnement objet mais avec une vitesse moindre. Enfin, c'est mon avis!

on va dire que ca c'est un détaille technique ... si microsoft à choisi d'émuler le comportement objet en l'exécutant sur la CLR, à la place d'avoir un modéle fondé sur le modèle orienté object.

mais fonctionnellement parlant, manquerait il quelque chose ?

[SQLpro]

La vitesse. Un SGBD objet se doit d'être plus rapide qu'un SGBD relationnel en ce qui concerne l'accès à un objet. Or Le CLR, proposait par SQL Pro, permet en effet de simuler le fonctionnement objet mais avec une vitesse moindre. Enfin, c'est mon avis!

D'ou tenez vous cette information ????

Amusez vous à implémenter un calcul de surface d'un polygone stocké sous forme relationelle (suite de points dans une tbale) en T-SQL et comparez la vitesse d'exécution de ce même calcul avec un polygone déclaré en GEOMETRY en appliquant la méthode STArea et dites moi ce qui est le plus rapide...

Mon grand père disait "une place pour chaque chose et chaque chose à sa place". Ni le relationnel pur, ni l'objet pur ne sont parfait... Chaque chose a son intérêt et dire que X est plus rapide que Y est idiot !

A +

[ylarvor]

Personnellement, si je voulais faire de l'objet avec un sgbd relationnel, je me tournerais plutôt vers hibernate, mapping objet relationnelle, que vers le CLR qui n'a pas pour fonction d'émuler un sgbd objet.

[omar.merroun]

Envoyé par ylarvor

Personnellement, si je voulais faire de l'objet avec un sgbd relationnel, je me tournerais plutôt vers hibernate, mapping objet relationnelle, que vers le CLR qui n'a pas pour fonction d'émuler un sgbd objet.

C'est un choix comme un autre ... dans ton cas c'est le administrateur du SGBD qui sera content, mais celui qui héberge ton application un peu moins (hibernate ça alourdi un peu)

et, inversement, si on choisit la CLR c'est l'administrateur du SGBD qui sera moins content car le SGBD fait plus de traitement, et l'hébergeur de ton appli plus soulagé (un framewok en moins)

[ylarvor]

l'idée, c'est surtout de faciliter le travail du developpeur, pour un objet, une simple configuration suffit sur hibernate, imagine que tu as 50 objets, avec le CLR, tu dois programmer 50 objets.

[omar.merroun]

Envoyé par ylarvor

l'idée, c'est surtout de faciliter le travail du developpeur, pour un objet, une simple configuration suffit sur hibernate, imagine que tu as 50 objets, avec le CLR, tu dois programmer 50 objets.

tu parles d'un développeur qui veut implanter une application rapidement (RAD) , je suis d'accord.