On 1/21/2011 2:16 AM, Nick Rudnick wrote:
> Dear all,
>
> for the sake academic teaching, a colleague asked me in how far
> PostgreSQL does support object functionality these days.
>
> I am afraid my web research was not very fruitful to him; the impression
> is that hardly anybody is occupied in working on PostgreSQL object
> functionality -- have ORM mappers grown so strong?
>
> The docs report that the SQL/OLB ISO/IEC 9075-10 part of the SQL
> standard have no implementation yet.
>
>
> Thanks a lot in advance,
>
> Nick
Short answer: no.
Here are some counter questions for you:
Have you ever seen any actual real world usage of OORDBMS?
Are there any products (good, useful products, not just academic
playthings) that support OORDBMS?
Bonus: If there is more than one product, do they share a common query
language?
You do realize that ORM sucks, right?
"Strict SQL standard conformance is less important than the possibility
to provide instructive and impressive examples to students."
Well! As long as its impressive! Who cares about anything else!
I've seen the buzword OODBMS for as long as OOP, and while OOP came and
went, OODBMS never amounted to anything. Let it go.
If anything, OODBMS transformed into webservices. There is your common
query language. JSON over HTTP!
OOP in code is easily understandable. OOData? It doesnt even make
sense. OOP in code means a container to hold your common data and code
together. In PG you can use a Schema to do the same thing. OOP needs
polymorphism. How does that even make sense with data? (Its a double
rainbow) WHAT DOES IT EVEN MEAN?!
Academia saw OOP revolutionize code, and I think they wanted something
to revolutionize data as well. We have a set of rules and procedures
for developing code... and those don't apply to data. (There is a tiny
little gray area however, when you get to stored procedures, which is
code, but dont let it fool you, its data).
In fact, what if I told you: Code is just data.
There, whew! I spent my existentialism for the month :-)
-Andy