| |||||||||||||
|
| |||||||||||||
PostgreSQL Weekly NewsPostgreSQL Weekly NewsPosted Apr 27, 2003 18:37 UTC (Sun) by leandro (subscriber, #1460)Parent article: PostgreSQL Weekly News So Codd is dead... without never seeing the full fruition of his relational model for database management. The sooner SQL is dead, and people disillusion themselves from OO, the sooner we will see Codd's victory!
(Log in to post comments)
PostgreSQL Weekly News Posted Apr 28, 2003 2:56 UTC (Mon) by coriordan (guest, #7544) [Link] Why kill SQL?I have a good knowledge of SQL but it's never been my main job so I can see it's uses but I've never researched it's limitations. Actually, I can't picture a way of accessing data that wouldn't be similar to SQL. I agree that "Object Oriented Databases" is a load of marketing crap, but what's the third option? Thanks for any info
PostgreSQL Weekly News Posted Apr 28, 2003 10:03 UTC (Mon) by Peter (guest, #1127) [Link] I agree that "Object Oriented Databases" is a load of marketing crap, but what's the third option? Why, XML databases, of course. They're out there now, inventing an XML-based language for running database queries. XML is this revolutionary new concept called structured data, so when they finally come up with XQuery or whatever it's called, finally the world will have a structured query language and we can all stop using SQL. ...Wait. What does SQL stand for again?
PostgreSQL Weekly News Posted May 8, 2003 13:43 UTC (Thu) by aurelien (guest, #11071) [Link] >> Why kill SQL?Because it's such a piece of shit as far as mapping the relational algebra semantics, which are what make RDBMS useful (and not only L. Ellison's cash cow).
PostgreSQL Weekly News Posted Apr 28, 2003 9:49 UTC (Mon) by haraldt (guest, #961) [Link] OO database may look like crap because old, well-known commercial database systems aren't built for object orientation from ground. So forgive me for being naïve, but I thought PostgreSQL could provide a good basis with its Posgres inheritance. PostgreSQL has oids, it has inheritance.. Making a function work as part of a table shouldn't be that hard, all compared?
PostgreSQL Weekly News Posted Apr 28, 2003 12:28 UTC (Mon) by Peter (guest, #1127) [Link] PostgreSQL has oids, it has inheritance.. Making a function work as part of a table shouldn't be that hard, all compared? It sounds like you just invented views. And stored procedures. And triggers. To have table output mix real data rows and rows generated from functions has it's uses anyway. That still sounds like views and stored procedures. Ah well, I'm not a DBMS guy. Assuming for the moment that "OO" databases are anything more than a shift in terminology, I probably wouldn't understand the advantages anyway. I'm so behind the times, my Java friends are still having trouble convincing me that exceptions are a worthwhile substitute for actual error handling.
PostgreSQL Weekly News Posted Apr 28, 2003 16:16 UTC (Mon) by haraldt (guest, #961) [Link] There isn't much invention. That's exactly the point. OO isn't more than a shift in terminology. Plus some important implications and some new functions related to that. OO is moving functionality inside the datasets, so the functions can work with a more limited dataset called "its own". So, I didn't mean more than make something unified out of a join between a data table and a number of view/function/whatever. And define a smart&simple way for the function to reference the data row currently being handled. If that's in place, you may find a way for a function to store data into the table row being referenced. Or even let a function create a brand new row and put data into it. Then, you can begin to worry about isolating/protecting the data entries so functions not defined to belong to that particular table row can't mess with it.
PostgreSQL Weekly News Posted Aug 7, 2003 21:06 UTC (Thu) by leandro (subscriber, #1460) [Link] > OO isn't more than a shift in terminology. Would it wasn't... actually OO in databases is going back 30 years to graph databases, like CODASYL, IDMS and IMS: the so-called network and hierarchical horrors. Even if it was, shifting terminology is evil, as it confuses even a situation that was already confused by SQL's crap terminology. Give me relationalspeak, please.
|
|
||||||||||||