On Sep 24, 2009, at 12:14 PM, ara.t.howard wrote:
that being said you may want to pick dan fitzpatrick's head - he's the
deepest in to the pg/ruby rabbit hole of anyone i know. i bcc'd him
on this message (not sure how the emails end up on the interwebs).
cheers.
--
-a
--
be kind whenever possible... it is always possible - h.h. the 14th
dalai lama
I built a system like this in 1995 with Perl CGI -> Applescript ->
FileMaker Pro. All the pages, layouts, and business logic where in the
database. FileMaker had great media capabilities at the time. We were
shooting pictures straight into the FileMaker client and the web app
was showing the media and meta data as it was added to the database. I
wrote report layouts that were html within FileMaker -- it did the
variable substitution and loops where needed. And these reports were
dynamically spit out to the browser clients via AppleScript and Perl.
Then I built something similar but way more complex with ColdFusion
and Oracle. I can say that it sounds great at first but is a complete
bear to maintain.
The only way to do most of what you are talking about successfully is
to store only meta data in the DB and the critical business rules in
pl/psql (not program flow). The data can be data about the view,
business logic, validation, etc. Then have a very thin app server that
pulls and processes the data act as the generic traffic cop or glue
between the user and their data using meta data about how to do what.
I highly recommend that the meta data about the app be in a different
database (or schema/namespace in postgres) than the real/customer
data. This one thing will make migrating, testing, and rolling back
when needed way easier.
All of this is doable and pretty maintainable if well architected but
I do not recommend it. It is harder to maintain than normal code.
Additionally, the database is always the bottleneck and the less you
use it the less of bottleneck you will have. I've sat in big sales
meetings with database vendors touting the advantages of "everything
in the database" - but that is because they are selling databases.
--
Dan Fitzpatrick
ePark Labs / http://eparklabs.com
+1 (970) 586-1086 / [email protected]
_______________________________________________
Bdrg-members mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/bdrg-members
