I have searched around, but I very rarely find any mention of Ruby with OO databases. YAML might work as a database, but I am hoping for something more like db4o.com's GPL database engine.
Does anyone attempt Ruby with something like db4o.com's oo database engine?
I personally think that relational storage is evil. It was built in a time where computers were much slower and much dumber, but we have not gotten any smarter. For transactional databases, it attempted to optimize speed and CRUD functions. For datawarehousing and business intelligence, relational databaes serve no purpose. Has anyone dealt with relational star and constellation schemas for datawarehouses? An oo structure would suit business intelligence software much better. Ruby on Rails only masks an underlying problem.
You could describe ORM as masking a problem or you could call it interfacing smartly. The problem with OO databases is that they're notoriously difficult to create and use. Perhaps not so much when only one process uses it, but quite a mess when you have many queries. I would argue that part of the problem is SQL being very unlike any non-database programming language. Building a database from the ground up, in an OOP language like Ruby is a fascinating idea but not for the squeamish or subgenius. Perhaps one of Matsumoto-san's coworkers, or Mr. DeNatale (a big Smalltalker) could address the concept better.
On Mar 21, 2007, at 12:29 AM, Demetrius Gallitzin wrote:
> I have searched around, but I very rarely find any mention of Ruby > with OO databases. YAML might work as a database, but I am hoping for > something more like db4o.com's GPL database engine.
> Does anyone attempt Ruby with something like db4o.com's oo database > engine?
> I personally think that relational storage is evil. It was built in a > time where computers were much slower and much dumber, but we have not > gotten any smarter. For transactional databases, it attempted to > optimize speed and CRUD functions. For datawarehousing and business > intelligence, relational databaes serve no purpose. Has anyone dealt > with relational star and constellation schemas for datawarehouses? An > oo structure would suit business intelligence software much better. > Ruby on Rails only masks an underlying problem.
On 3/20/07, Demetrius Gallitzin <gallit...@gmail.com> wrote:
> I have searched around, but I very rarely find any mention of Ruby > with OO databases. YAML might work as a database, but I am hoping for > something more like db4o.com's GPL database engine.
That's usually because OO databases aren't worth the code they're written in for most purposes. I've written about this extensively and recently; I suggest you search for it.
> Does anyone attempt Ruby with something like db4o.com's oo database > engine?
Someone probably has, although it's likely a waste of time.
> I personally think that relational storage is evil.
Then you're either ignorant or a fool. I hope it's just the former, because ignorance can be removed with proper education. Relational databases are a more natural and flexible way of storing data that has value beyond a single program than any hierarchical database will ever be (and both OO and XML databases are hierarchical databases, make no mistake about it!).
Object databases are fixed to a single representation of data; in reality, there are many ways to view data and so a far more flexible storage format is useful and necessary. Only people who don't understand data modelling (and *as such* also don't understand object modelling) would dismiss everything that Codd taught about data, relations, and relational algebra (set theory, basically), no matter how badly the current crop of SQL databases actually implement what he outlined.
> It was built in a time where computers were much slower and much > dumber, but we have not gotten any smarter.
You're incorrect on both your history and your assessment.
> For transactional databases, it attempted to optimize speed and CRUD > functions.
Again, this is incorrect. Relational algera are about set operations on data. SQL models this badly, but it allows for better data combination than any single OO model will ever allow.
> For datawarehousing and business intelligence, relational databaes > serve no purpose. Has anyone dealt with relational star and > constellation schemas for datawarehouses? An oo structure would suit > business intelligence software much better.
This is completely incorrect. A single given application or query may work better with a particular object model, but the whole set of applications that may run on databases are far better served by flexible models. If I can only access orders through customers, then I have exponentially increased the amount of work I must perform to find out which customers have ordered a particular line item.
> Ruby on Rails only masks an underlying problem.
This is correct, but only to the extent that Rails protects people from proper data modelling experience. Integration databases (cf Fowler) may be out of favour in Rails (in favour of application databases) but that doesn't mean that an application database may not be used in an integration fashion in the future as people find it necessary to do analysis on what is in the application database.
I don't see any value in this article at all, having worked in the real world with such problems. The solution is to have something that parses your DDL or database structure and generates your statically typed language, or work with a smarter language, like Ruby and a smart ORM mapper if you want automatic mapping (such as ActiveRecord or Og). Sometimes, you don't and a custom approach is better.
An OO database is almost never the answer to anything. An XML database is even less likely to be an answer.
1) Enterprise integration. Trying to put two relational database applications together costs as much effort as building one relational database application. This falls under the work of William McCarthy (Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise structures {now sold to Microsoft}. Putting data into normalized form seems to put things into unique patterns that are painful to integrate (with someone else's project). I look at two ERD diagrams for two applications, and then I'm told to make them work nicely together.
2) Business Analysis (OLAP and Data Mining) -- Decision support is interested in analyzing rather than processing data. Normalized data, to me, seems all about processing data. As the purpose of data analysis is to examine and uncover the redundancies in data, the uniqueness constraints placed on the relational model by the normalization process are not desirable for decision support (Roiger and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page 182). To me, it means that transaction databases in normalized form aren't structured well for OLAP or Data Mining type functions.
When you have business models and you're forced to think in terms of Codd's normalized form, it seems to kill the agile environment. I think in business terms, and then have to restructure the data into something foreign to the business....and a layer of maintainability and complexity above the business itself?
Even if OO databases are flawed, I'd rather be able to think OO, store OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :)
On 3/21/07, Austin Ziegler <halosta...@gmail.com> wrote:
> On 3/20/07, Demetrius Gallitzin <gallit...@gmail.com> wrote: > > I have searched around, but I very rarely find any mention of Ruby > > with OO databases. YAML might work as a database, but I am hoping for > > something more like db4o.com's GPL database engine.
> That's usually because OO databases aren't worth the code they're > written in for most purposes. I've written about this extensively and > recently; I suggest you search for it.
> > Does anyone attempt Ruby with something like db4o.com's oo database > > engine?
> Someone probably has, although it's likely a waste of time.
> > I personally think that relational storage is evil.
> Then you're either ignorant or a fool. I hope it's just the former, > because ignorance can be removed with proper education. Relational > databases are a more natural and flexible way of storing data that has > value beyond a single program than any hierarchical database will ever > be (and both OO and XML databases are hierarchical databases, make no > mistake about it!).
> Object databases are fixed to a single representation of data; in > reality, there are many ways to view data and so a far more flexible > storage format is useful and necessary. Only people who don't understand > data modelling (and *as such* also don't understand object modelling) > would dismiss everything that Codd taught about data, relations, and > relational algebra (set theory, basically), no matter how badly the > current crop of SQL databases actually implement what he outlined.
> > It was built in a time where computers were much slower and much > > dumber, but we have not gotten any smarter.
> You're incorrect on both your history and your assessment.
> > For transactional databases, it attempted to optimize speed and CRUD > > functions.
> Again, this is incorrect. Relational algera are about set operations on > data. SQL models this badly, but it allows for better data combination > than any single OO model will ever allow.
> > For datawarehousing and business intelligence, relational databaes > > serve no purpose. Has anyone dealt with relational star and > > constellation schemas for datawarehouses? An oo structure would suit > > business intelligence software much better.
> This is completely incorrect. A single given application or query may > work better with a particular object model, but the whole set of > applications that may run on databases are far better served by flexible > models. If I can only access orders through customers, then I have > exponentially increased the amount of work I must perform to find out > which customers have ordered a particular line item.
> > Ruby on Rails only masks an underlying problem.
> This is correct, but only to the extent that Rails protects people from > proper data modelling experience. Integration databases (cf Fowler) may > be out of favour in Rails (in favour of application databases) but that > doesn't mean that an application database may not be used in an > integration fashion in the future as people find it necessary to do > analysis on what is in the application database.
> I don't see any value in this article at all, having worked in the real > world with such problems. The solution is to have something that parses > your DDL or database structure and generates your statically typed > language, or work with a smarter language, like Ruby and a smart ORM > mapper if you want automatic mapping (such as ActiveRecord or Og). > Sometimes, you don't and a custom approach is better.
> An OO database is almost never the answer to anything. An XML database > is even less likely to be an answer.
has anybody used CACHE with ruby... it the best of both worlds and knocks the pants in performance off most relationals and it's reliable.... i am really curious... is it USA thing (against OO databases) because European Trade Schools CACHE is required learning... i've bought the only English translated text book authored by all German Professors... OO db design has to be in the database for better design thoroughness just as it accepted elsewhere in computer science. To topdown OO unit test the whole system and not just the ruby front end is better and more consisent....
On 3/20/07, Austin Ziegler <halosta...@gmail.com> wrote:
> That's usually because OO databases aren't worth the code they're > written in for most purposes. I've written about this extensively and > recently; I suggest you search for it.
> > I personally think that relational storage is evil.
> Then you're either ignorant or a fool. I hope it's just the former, > because ignorance can be removed with proper education. Relational > databases are a more natural and flexible way of storing data that has > value beyond a single program than any hierarchical database will ever > be (and both OO and XML databases are hierarchical databases, make no > mistake about it!).
On 3/20/07, Demetrius Gallitzin <gallit...@gmail.com> wrote:
> 1) Enterprise integration. Trying to put two relational database > applications together costs as much effort as building one relational > database application. This falls under the work of William McCarthy > (Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise > structures {now sold to Microsoft}. Putting data into normalized form > seems to put things into unique patterns that are painful to integrate > (with someone else's project). I look at two ERD diagrams for two > applications, and then I'm told to make them work nicely together.
Then you're integrating them wrong. If you can't integrate two databases, integrate two applications through application interfaces. See the writings of Fowler and, to some degree, of DHH. Sometimes it's useful to even take an approach where a "third" application is created (single sign-on, for example). This is not something that is helped *in the least* with OO databases. Repeat after me: OO databases aren't a solution to anything but a single problem.
> 2) Business Analysis (OLAP and Data Mining) -- Decision support is > interested in analyzing rather than processing data. Normalized data, > to me, seems all about processing data. As the purpose of data > analysis is to examine and uncover the redundancies in data, the > uniqueness constraints placed on the relational model by the > normalization process are not desirable for decision support (Roiger > and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page > 182). To me, it means that transaction databases in normalized form > aren't structured well for OLAP or Data Mining type functions.
Again, your understanding is wrong. Normalized data is about data representation. There's *nothing* wrong with the relational model for decision support or business analysis. There may be problems with the implementations of SQL databases, but set operations still apply to business analysis -- and OO databases *still* hurt here because they're only capable of asking a single question. DSS is all about asking *lots* of questions in *lots* of different ways to uncover yet other questions.
> When you have business models and you're forced to think in terms of > Codd's normalized form, it seems to kill the agile environment. I > think in business terms, and then have to restructure the data into > something foreign to the business....and a layer of maintainability > and complexity above the business itself?
I think that's a lack of imagination. When I was doing significant database work, I also thought in business terms. The team that had the problems with their database were the fools who thought that the database could be modelled based on the object model. They didn't think beyond their UI object model, which wasn't the *only* model necessary in the application (it was a billing application).
> Even if OO databases are flawed, I'd rather be able to think OO, store > OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :)
> On 3/20/07, Austin Ziegler <halosta...@gmail.com> wrote: > > That's usually because OO databases aren't worth the code they're > > written in for most purposes. I've written about this extensively and > > recently; I suggest you search for it.
> > > I personally think that relational storage is evil.
> > Then you're either ignorant or a fool. I hope it's just the former, > > because ignorance can be removed with proper education. Relational > > databases are a more natural and flexible way of storing data that has > > value beyond a single program than any hierarchical database will ever > > be (and both OO and XML databases are hierarchical databases, make no > > mistake about it!).
I'd never heard of these. The marketing speak sounds like hooey, and Fabian Pascal quite agrees. Fabian Pascal is, if you will, the Richard Dawkins of databases. He knows what the hell he's talking about, but he's an abrasive man who often hurts his own points by his abrasiveness. Here's three articles:
On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote:
> Again, this is incorrect. Relational algera are about set > operations on > data. SQL models this badly, but it allows for better data combination > than any single OO model will ever allow.
Just some random thoughts I had while reading this thread...
I'm curious as to why query language development got hung up on SQL. I've read a little bit about Tutorial D. Is SQL simply another example of pre-mature standardization?
What would a Ruby interface to the underlying database engine (indexed tables) look like? Could it get closer to Tutorial D by bypassing the standard technique of 'marshaling' requests into SQL statements? Is the impedance mismatch between Ruby (or any other OO language) and Codd's relational algebra too great to cross smoothly?
> I have searched around, but I very rarely find any mention of Ruby > with OO databases. YAML might work as a database, but I am hoping for > something more like db4o.com's GPL database engine.
> Does anyone attempt Ruby with something like db4o.com's oo database engine?
> I personally think that relational storage is evil. It was built in a > time where computers were much slower and much dumber, but we have not > gotten any smarter. For transactional databases, it attempted to > optimize speed and CRUD functions. For datawarehousing and business > intelligence, relational databaes serve no purpose. Has anyone dealt > with relational star and constellation schemas for datawarehouses? An > oo structure would suit business intelligence software much better. > Ruby on Rails only masks an underlying problem.
If you're interested I have written a Ruby OODB which uses an RDBMS as a storage back-end. It's called "Normal Ivy" or just "Norma" for short. It's just a prototype, at this point, which I wrote to ensure my idea would work. It does. But I haven't the time to polish it into a solid project. Of course, it will never be as efficient as a straight RDBMS, but it would certainly work well for many database needs. And since it uses a relational database on the back-end, many of Austin's criticisms can be countered through the use of VIEWS.
On Wed, Mar 21, 2007 at 04:17:55AM +0900, Gary Wright wrote: > Just some random thoughts I had while reading this thread...
> I'm curious as to why query language development got hung up on SQL. > I've read a little bit about Tutorial D. Is SQL simply > another example of pre-mature standardization?
On 3/20/07, Demetrius Gallitzin <gallit...@gmail.com> wrote:
> I am interested in several things. <snip>
> 2) Business Analysis (OLAP and Data Mining) -- Decision support is > interested in analyzing rather than processing data. Normalized data, > to me, seems all about processing data. As the purpose of data > analysis is to examine and uncover the redundancies in data, the > uniqueness constraints placed on the relational model by the > normalization process are not desirable for decision support (Roiger > and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page > 182). To me, it means that transaction databases in normalized form > aren't structured well for OLAP or Data Mining type functions.
<snip>
I have been working on the ActiveWarehouse project, which is a plugin for Rails designed to make it easier to develop data warehouses on Rails. As such I've spent the last 6 months research data warehouse techniques and technologies and have become quite interested as well. We use a denormalized dimensional model for our data warehouse, which is one way to develop a data warehouse, and it is working out quite well. With larger databases though, especially with both large facts and large dimensions, query response time degrades fairly quickly. In response to this I (and others in the AW development team) have been playing around with implementing alternate cube storage and query systems. One of the most promising is the Dwarf algorithm (http://citeseer.ist.psu.edu/sismanis02dwarf.html by Sismanis et. al) which I've been reading about for about 2 weeks now.
Anyhow, I recommend checking out the current trunk of ActiveWarehouse ( http://rubyforge.org/scm/?group_id=2435 ) to see if there is anything that piques your interest. We have also developed an ETL tool as well as some other Rails enhancements as well.
V/r Anthony Eden
-- Cell: 808 782-5046 Current Location: Melbourne, FL
On 3/20/07, Dave Rose <bitdog...@yahoo.com> wrote:
> has anybody used CACHE with ruby... it the best of both worlds and > knocks the pants in performance off most relationals and it's > reliable.... i am really curious...
Cache isn't the best both worlds; its marketing materials are completely unintelligible and useless nonsense. There is no such thing, as Fabian Pascal makes clear, that is "post-relational." SQL databases are a different matter, but Cache is an object database, which means that like *every other* object database, it has to do really nasty things to query in ways that don't fit your object model.
Anyone who bets their company on something which locks your data into a single query path and isn't readily adaptable deserves to lose that company. SQL databases are much more adaptable than object databases will ever be.
Object models are good for *single* applications. They are awful for dealing with a business as a whole.
> is it USA thing (against OO databases) because European Trade Schools > CACHE is required learning... i've bought the only English translated > text book authored by all German Professors...
Trade schools don't teach fundamentals. They teach the market line, and a whole bunch of schools (including some universities) do exactly the same thing in the U.S. and Canada.
SQL databases aren't perfect, but they are by and large far more sensible than an object database will ever be if you *ever* need to access the data in your database in a different way.
Data is king. Applications are pawns.
> OO db design has to be in the database for better design thoroughness > just as it accepted elsewhere in computer science. To topdown OO unit > test the whole system and not just the ruby front end is better and > more consisent....
This is incorrect in so many ways that it's not even worth addressing most of it. If you don't know proper data modelling, you will *never* be a good object modeller. If you don't understand the relational data model, you will *never* be a good object modeller.
> On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote: > > Again, this is incorrect. Relational algera are about set > > operations on > > data. SQL models this badly, but it allows for better data combination > > than any single OO model will ever allow. > Just some random thoughts I had while reading this thread...
> I'm curious as to why query language development got hung up on SQL. > I've read a little bit about Tutorial D. Is SQL simply > another example of pre-mature standardization?
Possibly. I haven't actually read Tutorial D.
> What would a Ruby interface to the underlying database engine (indexed > tables) look like? Could it get closer to Tutorial D by bypassing the > standard technique of 'marshaling' requests into SQL statements? Is > the impedance mismatch between Ruby (or any other OO language) and > Codd's relational algebra too great to cross smoothly?
Again, possibly to either one. I don't honestly know. What I do know is that people are looking for solutions in the wrong side. If you have a object/relational impedance mismatch, fix your object model.
On 3/20/07, Mark Volkmann <m...@ociweb.com> wrote:
> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote: > > He knows what the hell he's talking about, but > > he's an abrasive man who often hurts his own points by his > > abrasiveness. > Hmm ... this reminds me of somebody else (Austin) whose views I > usually agree with. ;-)
Like Pascal, I have little patience for people who speak out of ignorance, especially when they say stupid things like "I think relational databases are evil."
> On 3/20/07, Gary Wright <gwtm...@mac.com> wrote:
> > On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote: > > > Again, this is incorrect. Relational algera are about set > > > operations on > > > data. SQL models this badly, but it allows for better data combination > > > than any single OO model will ever allow. > > Just some random thoughts I had while reading this thread...
> > I'm curious as to why query language development got hung up on SQL. > > I've read a little bit about Tutorial D. Is SQL simply > > another example of pre-mature standardization?
> Possibly. I haven't actually read Tutorial D.
> > What would a Ruby interface to the underlying database engine (indexed > > tables) look like? Could it get closer to Tutorial D by bypassing the > > standard technique of 'marshaling' requests into SQL statements? Is > > the impedance mismatch between Ruby (or any other OO language) and > > Codd's relational algebra too great to cross smoothly?
> Again, possibly to either one. I don't honestly know. What I do know > is that people are looking for solutions in the wrong side. If you > have a object/relational impedance mismatch, fix your object model.
I've worked with SQL databases for at least 12 years now. As an admin, a report writer, a data analyst, you name it. The past 5 years I've tried to become more of a developer and have approached both OO and non-OO languages. I can agree with your assertions. Having checked out strict OO languages like the various Smalltalks and their accompanying OO databases I wound up loving the languages, with their elegance and their power. But when I started looking at testing out the OO databases they hook into I gave up with a bad taste in my mouth. They were such a PITA to even install and configure, let along start implementing as the back end of an application. The logic behind them just didn't make sense. I would spend hours trying to model something and just scrap it and spend a few minutes cranking out some SQL statements to post against a relational database. Sure you can use objects to solve problems constructing a user interface application. But the underlying data itself is a different story. Perhaps there are other OO databases out there that might shed some light I haven't seen yet. But after years of working with databases I haven't discovered anything that beats SQL.
On 20 Mar, 19:17, Gary Wright <gwtm...@mac.com> wrote:
> What would a Ruby interface to the underlying database engine (indexed > tables) look like? [...] Is > the impedance mismatch between Ruby (or any other OO language) and > Codd's relational algebra too great to cross smoothly?
IANADBA, but FWIW, here's one idea for dealing with the O-R impedance mismatch: model the queries, not the tables.
i.e. Create an API that makes it easy to perform relational database operations from an OO language, rather than trying to make a bunch of square data structures look like a big triangular one. Instead of writing a code generator that churns out custom classes to represent a database's tables, and then trying to shoehorn useful behaviours into that, define a set of standard classes and methods that represent the various database elements - table, query, result set, etc. - and the operations you'd perform on them - join, select, dump, etc. This might give users a basic syntax like:
d = database('My DB') t = d.table(:foo) + d.table(:bar) q = t[field(:size) > 100] r = q.get(:name, :color) r.each { |name, color| puts "#{name} likes #{color}" }
which could optionally be dressed up with a bit of db-specific syntactic sugar if desired, allowing users to write more concise expressions such as 'd.foo + d.bar', 't[it.size > 100]', etc.
It's an approach I used a couple years back when writing an Apple event bridge for Python. (Apple event-based IPC is an unusual mix of RPC and simple first-class queries with hybrid relational+object semantics.) While the resulting API may feel a little less OO-like than other Python-AE bridges that tried to put a strictly OO face on everything, its query-centric design made it significantly easier to expose the full range of AE functionality and created fewer hidden gotchas and compatibility problems. Admittedly, the full relational database model is a bit more complicated than the Apple Event Object Model, but given the issues with the traditional ORM approach, a query- centric approach could be worth a look.
> On Mar 20, 8:52 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> > On 3/20/07, Gary Wright <gwtm...@mac.com> wrote:
> > > On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote: > > > > Again, this is incorrect. Relational algera are about set > > > > operations on > > > > data. SQL models this badly, but it allows for better data combination > > > > than any single OO model will ever allow. > > > Just some random thoughts I had while reading this thread...
> > > I'm curious as to why query language development got hung up on SQL. > > > I've read a little bit about Tutorial D. Is SQL simply > > > another example of pre-mature standardization?
> > Possibly. I haven't actually read Tutorial D.
> > > What would a Ruby interface to the underlying database engine (indexed > > > tables) look like? Could it get closer to Tutorial D by bypassing the > > > standard technique of 'marshaling' requests into SQL statements? Is > > > the impedance mismatch between Ruby (or any other OO language) and > > > Codd's relational algebra too great to cross smoothly?
> > Again, possibly to either one. I don't honestly know. What I do know > > is that people are looking for solutions in the wrong side. If you > > have a object/relational impedance mismatch, fix your object model.
> I've worked with SQL databases for at least 12 years now. As an admin, > a report writer, a data analyst, you name it. The past 5 years I've > tried to become more of a developer and have approached both OO and > non-OO languages. I can agree with your assertions. Having checked out > strict OO languages like the various Smalltalks and their accompanying > OO databases I wound up loving the languages, with their elegance and > their power. But when I started looking at testing out the OO > databases they hook into I gave up with a bad taste in my mouth. They > were such a PITA to even install and configure, let along start > implementing as the back end of an application. The logic behind them > just didn't make sense. I would spend hours trying to model something > and just scrap it and spend a few minutes cranking out some SQL > statements to post against a relational database. Sure you can use > objects to solve problems constructing a user interface application. > But the underlying data itself is a different story. Perhaps there are > other OO databases out there that might shed some light I haven't seen > yet. But after years of working with databases I haven't discovered > anything that beats SQL.- Hide quoted text -
> - Show quoted text -
The other thing about this thread is the subject. Awesome title. Perhaps Angelina Jolie and Brad Pitt might look into adopting a data member :-)
Well, perhaps it is object orientation for object orientation's sake? Sometimes a program doesn't need objects either. Functional, procedural programming is sometimes the way to go. OOP helps organize code and reuse features, as well as protect data. But inside, even OOP is really procedural stuff that is just highly organized. At some level it is still procedural, to the machine.
> On 20 Mar, 19:17, Gary Wright <gwtm...@mac.com> wrote: >> What would a Ruby interface to the underlying database engine >> (indexed >> tables) look like? [...] Is >> the impedance mismatch between Ruby (or any other OO language) and >> Codd's relational algebra too great to cross smoothly?
> IANADBA, but FWIW, here's one idea for dealing with the O-R impedance > mismatch: model the queries, not the tables.
> i.e. Create an API that makes it easy to perform relational database > operations from an OO language, rather than trying to make a bunch of > square data structures look like a big triangular one. Instead of > writing a code generator that churns out custom classes to represent a > database's tables, and then trying to shoehorn useful behaviours into > that, define a set of standard classes and methods that represent the > various database elements - table, query, result set, etc. - and the > operations you'd perform on them - join, select, dump, etc. This might > give users a basic syntax like:
> which could optionally be dressed up with a bit of db-specific > syntactic sugar if desired, allowing users to write more concise > expressions such as 'd.foo + d.bar', 't[it.size > 100]', etc.
> It's an approach I used a couple years back when writing an Apple > event bridge for Python. (Apple event-based IPC is an unusual mix of > RPC and simple first-class queries with hybrid relational+object > semantics.) While the resulting API may feel a little less OO-like > than other Python-AE bridges that tried to put a strictly OO face on > everything, its query-centric design made it significantly easier to > expose the full range of AE functionality and created fewer hidden > gotchas and compatibility problems. Admittedly, the full relational > database model is a bit more complicated than the Apple Event Object > Model, but given the issues with the traditional ORM approach, a > query- > centric approach could be worth a look.
On Mar 20, 8:53 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> On 3/20/07, Mark Volkmann <m...@ociweb.com> wrote:
> > On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote: > > > He knows what the hell he's talking about, but > > > he's an abrasive man who often hurts his own points by his > > > abrasiveness. > > Hmm ... this reminds me of somebody else (Austin) whose views I > > usually agree with. ;-)
> Like Pascal, I have little patience for people who speak out of > ignorance, especially when they say stupid things like "I think > relational databases are evil."
Oh, like you've never said anything "stupid" before. Ha! :)
Austin Ziegler wrote: > On 3/20/07, Mark Volkmann <m...@ociweb.com> wrote: >> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote: >> > He knows what the hell he's talking about, but >> > he's an abrasive man who often hurts his own points by his >> > abrasiveness. >> Hmm ... this reminds me of somebody else (Austin) whose views I >> usually agree with. ;-)
> Like Pascal, I have little patience for people who speak out of > ignorance, especially when they say stupid things like "I think > relational databases are evil."
Having read Pascal's articles (and a few posts by some notable others on comp.databases.theory), I'd say you're remarkably mild and restrained...
> I'm curious as to why query language development got hung up on SQL. > I've read a little bit about Tutorial D. Is SQL simply > another example of pre-mature standardization?
From memory, and as far I've understood it: Sometime during the early 80s there was a rush to get relational databases out there, with several vendors producing databases and wanting an interoperable query language. As a result of some sort of differences, two different groups were formed, both creating their own attempt at a standard query language. Over time, a bunch of rivalry formed between the groups, and each of the languages they developed had advantages in some areas and disadvantages in others, so it wasn't possible to pick a single "winner", and everything kept bickering back and forth. Prestige entered, and none of the groups were politically able to give in to the other.
Along came SQL, which was a toy language made by a single developer to just show have SOMETHING. It was worse than either of the proposals from the other groups, from a usability point of view (though with a couple of extra features I don't remember what was that were useful), and it was a possible political compromise. So, by shooting down BOTH groups for something that was worse, a solution was possible. Thus, we standardized on SQL.
Take with a grain of salt - this is based on renderings of history I've read on the net, and reproduced from my spotty memory. Yet it's a nice story that fits very well with my feeling about SQL ("Nobody could really have meant that language SERIOUSLY, could they?")
Reality was uglier than that. More comparable to the browser wars and implementations of html of the 90's. But worse. All the database makers had their own ways of doing things. SQL was a pseudo-standard middle between systems that always offered their own proprietary things as well. Like html and C/C++ and JavaScript and everything else out there, vendors slowly merged toward more fully supporting a standard by customer demand. You don't think Microsoft was the first to think up the idea of using proprietary things to lock in customers, do you? Databases were the original home of neckties running IT. Everyone was calling their SQL the real one, but none were the same. (still aren't really) because they don't want you to jump ship so easily! Long term licensing revenues with low support costs. On Mar 21, 2007, at 11:44 PM, Eivind Eklund wrote:
> On 3/20/07, Gary Wright <gwtm...@mac.com> wrote: >> I'm curious as to why query language development got hung up on SQL. >> I've read a little bit about Tutorial D. Is SQL simply >> another example of pre-mature standardization?
> From memory, and as far I've understood it: Sometime during the early > 80s there was a rush to get relational databases out there, with > several vendors producing databases and wanting an interoperable query > language. As a result of some sort of differences, two different > groups were formed, both creating their own attempt at a standard > query language. Over time, a bunch of rivalry formed between the > groups, and each of the languages they developed had advantages in > some areas and disadvantages in others, so it wasn't possible to pick > a single "winner", and everything kept bickering back and forth. > Prestige entered, and none of the groups were politically able to give > in to the other.
> Along came SQL, which was a toy language made by a single developer to > just show have SOMETHING. It was worse than either of the proposals > from the other groups, from a usability point of view (though with a > couple of extra features I don't remember what was that were useful), > and it was a possible political compromise. So, by shooting down BOTH > groups for something that was worse, a solution was possible. Thus, > we standardized on SQL.
> Take with a grain of salt - this is based on renderings of history > I've read on the net, and reproduced from my spotty memory. Yet it's > a nice story that fits very well with my feeling about SQL ("Nobody > could really have meant that language SERIOUSLY, could they?")
> I would argue that part of the problem is SQL being very unlike any > non-database programming language.
That may be because SQL is not a programming language although it is often mistaken for one. SQL, more precisely the query part of it, *describes* data sets via set operations.
Although there are declarative languages around (IIRC Prolog is one of them) most programming languages are procedural (even OO languages) and so people tend to expect SQL to be similar.
|
