«

On Mar 20, 11:29 am, "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.
>
> 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/2...ietnam%20of%20...
> (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.

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

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

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/
*

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/
*

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/
*

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.
>
> -austin
> --
> Austin Ziegler * halosta...@gmail.com *http://www.halostatue.ca/
> * aus...@halostatue.ca *http://www.halostatue.ca/feed/
> * aus...@zieglers.ca

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.

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

On Mar 20, 9:44 pm, "gregarican" <greg.kuj...@gmail.com> wrote:
> 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.
>
> > -austin
> > --
> > Austin Ziegler * halosta...@gmail.com *http://www.halostatue.ca/
> > * aus...@halostatue.ca *http://www.halostatue.ca/feed/
> > * aus...@zieglers.ca
>
> 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 Mar 21, 2007, at 10:50 AM, has wrote:

> 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.
>
> has
> --
> http://appscript.sourceforge.net
> http://rb-appscript.rubyforge.org
> http://appscript.sourceforge.net/objc-appscript.html
>
>