Objets dans PostgreSQL

Je ne suis pas sûr de ce que vous voulez dire avec "Introduction d'objets dans des systèmes relationnels". PostgreSQL a en effet des types personnalisés, mais ce ne sont rien comme OOP.

afaik la seule raison pour laquelle PostgreSQL est parfois appelé une "base de données d'objet-relation" est parce qu'il Soutenir l'héritage de la table . Cependant, le cas d'utilisation principale d'héritage a été Supprimer certaines de ces limitations ).

Bottom Line: Rien à voir ici, PostgreSQL est juste une autre base de données relationnelle.

La préface du Postgres 7 La documentation explique pourquoi ils se considèrent comme ayant été pionniers Concepts relationnels (à Postgres 8 et plus tard, cela a tout reproduit / restructuré / supprimé). Document d'historique donne plus de détails.

Eh bien, d'un point de vue, PostgreSQL peut prendre en compte les entités de tables en tant que type composite qui peut être vue comme des objets.

SELECT 
  author.id, 
  author.name,
  array_agg(post) AS posts
FROM 
  author 
    LEFT JOIN post ON 
        author.id = post.author_id 
GROUP BY 
  author.id;
| id |   name   |                  posts                 |
+----+----------+----------------------------------------+
|  1 | John Doe | {"(1,'first post')","(2,'new post')"}  |
+----+----------+----------------------------------------+
|  2 | Edgar    | {"(3,'Hello world')"}                  |
+----+----------+----------------------------------------+

Les documents historiques disent au conte, mais j'ai été surpris de voir que tant de commentateurs mentionnaient la programmation orientée objet, qui est entièrement un sujet séparé.

Postgres a commencé à UC Berkeley en tant que projet de recherche au sol, dirigé par Michael Stonebraker, qui a précédemment dirigé le projet de développement Ingres.

L'exemple classique d'une base de données relationnelle d'objet impliquait le stockage et la récupération des données non tabulaires, telles que des images, de l'audio, des médias, etc. StoneBeaker forgit l'explosion de la "explosion des données", en particulier dans la zone des gros objets binaires, tels que comme des images, etc., et ont compris que les RDBM traditionnels n'étaient pas à la hauteur de la tâche.

L'un des exemples utilisés pour décrire "la vision" était la nécessité de rechercher une base de données d'images, des images de couchers de soleil, en fonction des attributs des données elles-mêmes, pas simplement des méta-données (noms avec la chaîne "Sunset", étiquettes, etc.). Le concept impliquait le développement des méthodes d'indexation révolutionnaires, par exemple, sur la base du spectre des couleurs dominant (les couchers de soleil ont tendance à être rouges, orange) ou d'autres attributs, en fonction du type de données. Ces idées ont été commercialisées sur le produit illustra, qui était un descendant direct du travail d'une équipe Postgres d'origine.

En fait, la plupart des fonctionnalités ORDBMS ont été soustraits de la base de code Postgres, qui est devenue que postgretsql que nous connaissons aujourd'hui. En ce sens, la conclusion est correcte. Même PostgreSQL manque de l'aspect ORDBMS des postgres d'origine.

donc, objets à Oracle? Toujours pas là. Oop dans une SGBDM? Pas le même sujet du tout.

Autant que je sache, le premier RDBM offre une prise en charge des objets à pleine échelle (celle avec des types définis par l'utilisateur, la nidification, la relation de détail maître, etc.) était Oracle. Ils ont même ajouté héritage dans les versions ultérieures, mais à mon avis, c'était une overcive. Voir exemple de script SQL extrait de la très vieille installation de client Oracle (plus de 15 ans).

drop view department;
drop type dept_t;
drop type emp_list;
drop type emp_t;
create or replace type emp_t as object (
  empno number,
  ename varchar2(80),
  sal   number
);    
/

create or replace type emp_list as table of emp_t;    
/

create or replace type dept_t as object (
  deptno number, 
  dname varchar2(80),
  loc   varchar2(80),
  employees emp_list
);    
/

create or replace view department of dept_t
with object OID (deptno)
as select deptno, dname, loc,
          cast(multiset(select empno, ename, sal 
                        from emp 
                        where emp.deptno = dept.deptno
                        ) as emp_list ) employees
     from dept;

create trigger department_ins
instead of insert on department
for each row 
declare
  emps emp_list;
  emp  emp_t;
begin
  -- Insert the master
  insert into dept( deptno, dname, loc ) 
  values (:new.deptno, :new.dname, :new.loc);

  -- Insert the details
  emps := :new.employees;
  for i in 1..emps.count loop
    emp := emps(i);
    insert into emp(deptno, empno, ename, sal)
    values (:new.deptno, emp.empno, emp.ename, emp.sal);
  end loop;
end;    
/

Comme mentionné par Martin v. Löwis, le Old PostgreSQL 7 Document répertorie simplement les 3 points suivants de cette rubrique:

• Héritage (héritage de la table)
• Types de données (POSTRESQL prend en charge JSON, TRAY et HSTORE)
• Fonctions

  IMHO, je suppose que ces fonctionnalités ont été tranchantes lorsque PostgreSQL les a présentés dans les années 80, ce qui, toutefois, sont largement disponibles dans d'autres bases de données de nos jours. Alors que PostgreSQL marketing toujours le terme "objet" et les personnes sont confondues.