Ruby on Rails version of osCommerce in PHP?

[Paul]

You can always plug a BI type system (Crystal, Hyperion, etc) into a db
used by rails and most of these will provide some level of ad hoc
quering for business report purposes. They key here is that none of
these systems will modify data and so shouldn't effect its integrity.
There might be problems if you have a particular schema elements or
particular access control requirements, but otherwise things should be
ok.

As an alternative, you could probably build an XML exporter that MS SQL
2k5 could consume. I wonder if you could even call SOAP from within a
MS SQL 2k5 database to pull data from a rails app given that its now a
full .NET environment?

 

[David Heinemeier Hansson]

Ah ... but at that point, in many ways, he's wrong. The moment you have

data to migrate, there's a second program working on the database.
Unless -- as appears to be the case with Rails at this point -- your
migration is done using the exact same database access layer as your
primary application, you will get garbage data at some point.

To quote from the article (especially the "my opinions are confined to
dealing with application databases"):

"Before the DBA-induced side of your brain explodes at that statement,
please do read Martin Fowler's article on the difference between
application and integration databases. And realize that my opinions
are confined to dealing with application databases (and that doing
integration through the database belongs in a time where Beverly Hills
90210 was a hit show on TV). Hopefully that calmed you down again."

But it was my fault. I should have decorated that caveat with
underline, bold, and possibly blink.

So actually we're very much in agreement. My strong opinions on this
matter are strongly scoped. What we might agree on is whether that
scope is a desireable one or not.

And to further the group hug, I'm pretty neutral about foreign key
constraints. It's triggers, business constraints ("don't insert if
balance > 100"), and stored procedures that deserve the "Evil" label.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[Austin Ziegler]

Ah ... but at that point, in many ways, he's wrong. The moment you
have data to migrate, there's a second program working on the
database. Unless -- as appears to be the case with Rails at this
point -- your migration is done using the exact same database access
layer as your primary application, you will get garbage data at some
point.

To quote from the article (especially the "my opinions are confined to
dealing with application databases"):

[...]

But it was my fault. I should have decorated that caveat with
underline, bold, and possibly blink.

David, for what it's worth, I have more of a problem with how most
people misinterpret what you've said than what you've said. Having
discussed it with you in person, I understand where you're coming from.

So actually we're very much in agreement. My strong opinions on this
matter are strongly scoped. What we might agree on is whether that
scope is a desireable one or not.

If you can guarantee that a particular database is only going to be an
application database, then I think that the scope is somewhat desirable.
In my experience, though, business people come to realise the overall
value of the data in that database and start wanting additional ways of
getting, manipulating, and reporting on that data. I have experienced
cases where single-purpose databases have become multi-purpose.

What I *fear* is that while Rails encourages good program design, it
ends up encouraging bad database design at the same time.

And to further the group hug, I'm pretty neutral about foreign key
constraints. It's triggers, business constraints ("don't insert if
balance > 100"), and stored procedures that deserve the "Evil" label.

Yeah. I'm a cheerleader for foreign keys and hate that my embedded
database of choice (sqlite) doesn't support them in any way. There are
times when business constraints can be useful -- but the "proper" way of
doing that would actually be to abstract the relational information one
level further (e.g., if something can only be 'y' or 'n', then there
should be a *table* with a FK that contains the 'y' and 'n' values).

I will argue for the pushing of business logic into the database when
you hit an integration database stage or possibly access the data
through multiple mechanisms (perhaps in different languages) just so
that you don't violate DRY.

But by and large, most people put too much business logic in the
database.

-austin

 

[David Heinemeier Hansson]

Yeah. I'm a cheerleader for foreign keys and hate that my embedded

database of choice (sqlite) doesn't support them in any way. There are
times when business constraints can be useful -- but the "proper" way of
doing that would actually be to abstract the relational information one
level further (e.g., if something can only be 'y' or 'n', then there
should be a *table* with a FK that contains the 'y' and 'n' values).

On the notion of foreign keys, let this serve as an open invitation to
anyone that wants to implement support for dumping and migrating those
through the facilities in Active Record. We don't currently support
them at all. It would be nice to do that.

I will argue for the pushing of business logic into the database when
you hit an integration database stage or possibly access the data
through multiple mechanisms (perhaps in different languages) just so
that you don't violate DRY.

I totally agree. But I would be on the barricades to guard such a move
in the first place. There are so many other ways of integrating
applications and data that doesn't involve sidestepping the domain
model. But if you're forced to do it, you basically need every logic
trick in the book to keep you DRY and safe.

But by and large, most people put too much business logic in the
database.

Hear, hear . Objects, baby. That's where its at.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework