Object/Relational Mapping is the Vietnam of Computer Science

Discussion in 'Ruby' started by Demetrius Gallitzin, Mar 20, 2007.

  1. 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.

    Reference that inspired the subject's title:
    http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx
    http://www.odbms.org/download/031.01 Neward The Vietnam of Computer Science June 2006.PDF
    (pdf from odbms.org)
    Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.
     
    Demetrius Gallitzin, Mar 20, 2007
    #1
    1. Advertising

  2. Demetrius Gallitzin

    John Joyce Guest

    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.
    >
    > Reference that inspired the subject's title:
    > http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer
    > +Science.aspx
    > http://www.odbms.org/download/031.01 Neward The Vietnam of%
    > 20Computer%20Science%20June%202006.PDF
    > (pdf from odbms.org)
    > Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org,
    > etc. etc.
    >
     
    John Joyce, Mar 20, 2007
    #2
    1. Advertising

  3. On 3/20/07, 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.


    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.

    > Reference that inspired the subject's title:
    > http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx


    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.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 20, 2007
    #3
  4. I am interested in several things.

    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 <> wrote:
    > On 3/20/07, 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.

    >
    > 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.
    >
    > > Reference that inspired the subject's title:
    > > http://blogs.tedneward.com/2006/06/26/The Vietnam Of Computer Science.aspx

    >
    > 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.
    >
    > -austin
    > --
    > Austin Ziegler * * http://www.halostatue.ca/
    > * * http://www.halostatue.ca/feed/
    > *
    >
    >
     
    Demetrius Gallitzin, Mar 20, 2007
    #4
  5. Demetrius Gallitzin

    Dave Rose Guest

    Re: Object/Relational Mapping is the Vietnam of Computer Sci

    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....


    --
    Posted via http://www.ruby-forum.com/.
     
    Dave Rose, Mar 20, 2007
    #5
  6. Demetrius Gallitzin

    Guest

    On 3/20/07, Austin Ziegler <> 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!).


    Anyone have any comments / experience with "associative" databases like:
    http://www.associativesolutions.com/relavance.php
    http://www.lazysoft.com/technology_sentences.htm
     
    , Mar 20, 2007
    #6
  7. On 3/20/07, Demetrius Gallitzin <> 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. :)


    OO databases aren't flawed. They're disastrous.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 20, 2007
    #7
  8. On 3/20/07, <> wrote:
    > On 3/20/07, Austin Ziegler <> 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!).

    >
    > Anyone have any comments / experience with "associative" databases like:
    > http://www.associativesolutions.com/relavance.php
    > http://www.lazysoft.com/technology_sentences.htm


    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:

    http://www.dbdebunk.com/page/page/622443.htm
    http://www.dbdebunk.com/page/page/622368.htm
    http://www.dbdebunk.com/page/page/3278346.htm

    I suspect that these are to be heavily avoided in favour of properly
    educating oneself about relational data models.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 20, 2007
    #8
  9. Demetrius Gallitzin

    Gary Wright Guest

    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?

    Gary Wright
     
    Gary Wright, Mar 20, 2007
    #9
  10. 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. ;-)
     
    Mark Volkmann, Mar 20, 2007
    #10
  11. Demetrius Gallitzin

    Trans Guest

    On Mar 20, 11: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.
    >
    > Reference that inspired the subject's title:http://blogs.tedneward.com/2006/06/...ms.org/download/031.01 Neward The Vietnam of ...
    > (pdf from odbms.org)
    > Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.


    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.

    T.
     
    Trans, Mar 20, 2007
    #11
  12. Demetrius Gallitzin

    Jos Backus Guest

    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?


    There's QUEL, too:

    http://www.vldb.org/conf/1987/P083.PDF

    --
    Jos Backus
    jos at catnook.com
     
    Jos Backus, Mar 20, 2007
    #12
  13. Demetrius Gallitzin

    Anthony Eden Guest

    Demetrius,

    Response below...

    On 3/20/07, Demetrius Gallitzin <> 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
     
    Anthony Eden, Mar 20, 2007
    #13
  14. Re: Object/Relational Mapping is the Vietnam of Computer Sci

    On 3/20/07, Dave Rose <> 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.

    Period.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 21, 2007
    #14
  15. On 3/20/07, Gary Wright <> 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.

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 21, 2007
    #15
  16. On 3/20/07, Mark Volkmann <> 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."

    -austin
    --
    Austin Ziegler * * http://www.halostatue.ca/
    * * http://www.halostatue.ca/feed/
    *
     
    Austin Ziegler, Mar 21, 2007
    #16
  17. Demetrius Gallitzin

    gregarican Guest

    On Mar 20, 8:52 pm, "Austin Ziegler" <> wrote:
    > On 3/20/07, Gary Wright <> 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.
    >
    > -austin
    > --
    > Austin Ziegler * *http://www.halostatue.ca/
    > * *http://www.halostatue.ca/feed/
    > *


    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.
     
    gregarican, Mar 21, 2007
    #17
  18. Demetrius Gallitzin

    has Guest

    On 20 Mar, 19:17, Gary Wright <> 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.

    has
    --
    http://appscript.sourceforge.net
    http://rb-appscript.rubyforge.org
    http://appscript.sourceforge.net/objc-appscript.html
     
    has, Mar 21, 2007
    #18
  19. Demetrius Gallitzin

    gregarican Guest

    On Mar 20, 9:44 pm, "gregarican" <> wrote:
    > On Mar 20, 8:52 pm, "Austin Ziegler" <> wrote:
    >
    >
    >
    >
    >
    > > On 3/20/07, Gary Wright <> 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.

    >
    > > -austin
    > > --
    > > Austin Ziegler * *http://www.halostatue.ca/
    > > * *http://www.halostatue.ca/feed/
    > > *

    >
    > 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 :)
     
    gregarican, Mar 21, 2007
    #19
  20. Demetrius Gallitzin

    John Joyce Guest

    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 Mar 21, 2007, at 10:50 AM, has wrote:

    > On 20 Mar, 19:17, Gary Wright <> 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.
    >
    > has
    > --
    > http://appscript.sourceforge.net
    > http://rb-appscript.rubyforge.org
    > http://appscript.sourceforge.net/objc-appscript.html
    >
    >
     
    John Joyce, Mar 21, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. A. M. G. Solo
    Replies:
    0
    Views:
    586
    A. M. G. Solo
    Jan 13, 2006
  2. A. M. G. Solo
    Replies:
    0
    Views:
    822
    A. M. G. Solo
    Jun 8, 2006
  3. A. M. G. Solo (do not reply to this email address)
    Replies:
    0
    Views:
    749
    A. M. G. Solo (do not reply to this email address)
    Nov 8, 2006
  4. A. M. G. Solo
    Replies:
    0
    Views:
    769
    A. M. G. Solo
    Dec 5, 2006
  5. A. M. G. Solo
    Replies:
    0
    Views:
    743
    A. M. G. Solo
    Jan 25, 2007
Loading...

Share This Page