Re: chooses not to generate code at all
- From: JXStern <JXSternChangeX2R@xxxxxxx>
- Date: Sun, 21 Aug 2005 16:22:36 GMT
On Sat, 20 Aug 2005 19:06:47 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:
>> In database, I suppose one can say the architecture is driven by the
>> data model in any particular application, but sadly, this
>> formalization does not extend to the guts of stored procedures, etc.
>> There is debate about how much business logic even belongs in the
>> database, and most people think some or ALL of it belongs outside.
>> Otherwise we'd have to call SQLServer an MDA system, and that doesn't
>> seem right to me. How about you?
>
>I belong to the camp that thinks nothing should be in stored procedures
>except rules related to data integrity that have the stability of
>Keplar's or Maxwell's Laws.
Do they have canoeing and archery at that camp?
I don't know how to turn that kind of statement into a decision
process, since any rule that is true, is as true as Maxwell's Laws.
The issue is which rules are a part of the data model, and which are
application-specific. Well, I'm not sure how to turn that into a
decision process either, except by taking a poll, but at least it
doesn't depend on making judgements about eternal truth.
Pragmatically, it seems to turn on whether you want to enforce a
certain behavior across all applications that are ever going to touch
a database, even if that behavior is arguable and evanescent. It's
more of an architectural issue than a contentful one.
>FWIW, I think SQL is an implementation of MDA principles because it
>enables a generic transformation from one model representation
>(application data) to another (RDB storage). In the end MDA is simply:
>
>[Input Model] [Transformation Model]
> | |
> | |
> V |
>{Transformation} <----------+
> |
> |
> V
>[Output Model]
>
>If we have an Input Model of objects, C structs, FORTRAN arrays, or
>whatever for a specific application and we need to turn it into an RDB
>representation (schemas, tables, tuples), then SQL is one Transformation
>Model that formalizes that conversion. The actual Transformation can be
>done manually by the developer in the 3GL de jour or it can be automated
>by a full code generator.
Well, to start with, SQL is not the model, but relational algebra is,
SQL is just one language that operates in that domain. And neither
relational nor SQL prescribe any transformation from outside
representations, though reduction to cannonical form is a common
practice in and around relational, but its strength comes from the
existence of the cannonical form, not from being a process.
But if we want to explore the idea that relational database is a sort
of MDA, then we return to the previous question - is the part of
relational technology that is formalized, which is just the tables and
relations and not code in triggers or stored procedures, enough to
even constitute a "model" in MDA terms? And I'm in the camp that
thinks not. In this camp we also learn how to tie knots and find
edible foods in the forest.
J.
.
- Follow-Ups:
- Re: chooses not to generate code at all
- From: H. S. Lahman
- Re: chooses not to generate code at all
- References:
- Re: chooses not to generate code at all
- From: H. S. Lahman
- Re: chooses not to generate code at all
- From: JXStern
- Re: chooses not to generate code at all
- From: H. S. Lahman
- Re: chooses not to generate code at all
- Prev by Date: Re: RUP: Can I Implement a Use-Case Partially?
- Next by Date: Re: XP and Pair Programming
- Previous by thread: Re: chooses not to generate code at all
- Next by thread: Re: chooses not to generate code at all
- Index(es):
Relevant Pages
|
