From: Corey Lawson <corey.ssf.lawson@...>
Date: 2005-10-28T00:26:34+09:00
Subject: Re: Ruby on Rails version of osCommerce in PHP?

------=_Part_8125_22075675.1130426792365
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/27/05, Paul <paul.vaillant@gmail.com> wrote:
>
> As for triggers and stored procedures, I'm not so neutral. Just as VB's
> promoted bad UI, I've seen DBAs go wild with stored procedures and you
> can have a mess on your hands there too. Any tool or system in the
> hands of the inexperienced can promote bad something-or-other. Good
> design is key.


Some DBAs may go wild with SPs, but the worst by far is Access. I love it
for what it is (a very accessible[sic] database environment, but I hate
having to deal with apps other people make that have grown into
business-essential apps. The least problem is the "Excel" mentality of some
"developers". The hardest problems are that it is not possible to decouple
data integrity at the database level from the user interface (i.e.,
triggers/procs). It's been like this for about 15 or so years. You think
someone might have figured out a better way to do it?

And rails and family do consistently access the database in the same

> way which may be how David rationalizes to himself what he says. If so,
> then that makes sense because rails also provides the ability to add
> messaging hooks (via ActiveWebService) to implement the integration
> mechanizms that he advocates. In another system, if this full stack
> weren't in place, then other mechanizms would be required because you'd
> be integrating at some point or other in the database (even if its only
> one system for web and other for messaging). Martin Fowler talks about
> this http://martinfowler.com/bliki/DatabaseStyles.html.



If only there were a Rails-based data transporter mechanism (ala DTS for SQ=
L
Server), a multiplatform Rails-based ad hoc query system, several
Rails-based reporting and data analysis systems (Crystal Reports, Hyperion,
et al), or a Rails-based "glue" layer that could easily provide a homogenou=
s
access layer for heterogenous data sources to external applications (ala
ODBC. AR works within Rails, but not for things outside of Rails).

The messaging hooks will work with Rails, but what about external
applications?

------=_Part_8125_22075675.1130426792365--