Uwe Schroeder wrote:
>
>
>
> Funny, this sounds a lot like financial industry or government to me
> (spent
> years in that sector).
>
> Here's a point that hasn't been made yet: you can pretty much skip all the
> ORM
> features of SQLAlchemy and just issue plain old SQL statements directly to
> the
> engine. That's one of the reasons why I used and still use TG. Personally
> I
> hate ORMs as for me - someone who can actually write SQL with no intention
> to
> switch databases - it's overly complicated to form a 10 line pretty much
> unreadable statement in python that's just one line in SQL. But that may
> just
> be me.
> Complicated joins however are a PITA with an ORM, so I use
> views and procedures for those, just to map them via the ORM in a simple
> "select whatever from (view, procedure) where (restriction)". Whenever I
> need
> to change the logic I don't even touch the python code - I just change the
> view or procedure and best of all I can do it while in production and the
> next
> request will get the new version. That really suits my insurance
> customers.
>
> Uwe
>
>
>
I tend to side with Uwe with this one, but then the application DB in
question is accessed by multiple toolsets.
I would lean towards the ORM for an application that is wholly contained
within Turbogears, but in this case that is not possible.
For one example, most organizations have their own reporting tool standards,
that need to access the core data.
For another, the system sources data from and feeds transactions back to 10s
or 100s of other applications. To do this it makes use of a variety of
existing and developed technologies, for example proprietary provisioning
tools, or MS SSIS, .
It also has a fairly complex (to understand, if not implement) schema, in
that most entities are stored in a single 'Object' table, and related by a
modified bill of material structure (as an example of just one type of
data). There are a number of logical data entities that can be several
levels deep (think of walking the tree when exploding out a car, assemblies,
sub assemblies, parts, components and so on).
Everything, including about all the configuration and lookup tables, is
audited via triggers.
There are several updatable views that represent different objects in the
system (objects being spread across multiple tables), hierarchical views
that explode out these trees, and a lot of stored procedures that control
how data is updated in the system.
There are several embedded application components totaling several thousand
(tens of thousands?) lines of code that I just don't want to or cannot redo,
and most of these are driven through stored procedures, functions and views.
I guess I've just talked myself out of Django or RoR based on the other
input I've received here :)
--
View this message in context:
http://old.nabble.com/Why-TG-is-a-better-option-than-RoR--tp31033408p31076993.html
Sent from the Turbogears General mailing list archive at Nabble.com.
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
