Re: Object-relational impedence

From: TroyK <cs_troyk_at_juno.com>
Date: Tue, 11 Mar 2008 10:04:46 -0700 (PDT)
Message-ID: <688b01d1-0367-47ef-8868-50d2155b8b83_at_b64g2000hsa.googlegroups.com>


On Mar 10, 4:53 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> TroyK wrote:
> > On Mar 8, 7:09 am, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
>
> >>TroyK  wrote:
>
> >>>Who said anything about stored procedures? I'm talking about
> >>>implementing the business rules via constraint declaration in the
> >>>database, and deriving new values throught the application of SQL
> >>>queries.
>
> >>Do you also treat dynamic constraints in this way?
>
> >>E.g. "unless otherwise specified, an employee shall get a 2%
> >>salary increase after each full year of employment".
>
> with not_excluded_ee = (
>   employees join ( employees{ee#} minus excluded_ees{ee#} )
> ), increases = extend (
>    not_excluded_ee where is_anniversary_period(pay_period(now),hire_date)
> ) add increase = salary * percent(2)
> ...
>
> >>Or: "two movable 3D shapes shall never collide; collision is avoided
> >>by the following repositioning algorithm that is guaranteed
> >>to pull all objects apart that get too close: (...), however, this
> >>algorithm may be replaced with another that has the same property".
>
> with other_objects = objects rename all prepending "other_"
> , collisions = objects join other_objects
>    where rank_attrib < other_rank_attrib
>      and min_distance(polygons,other_polygons) < threshold_distance
> , while exists(collisions) {
>      update collisions
>      set position = ...
>      , other_position = ...
>
> }
>
> >>--
> >>Reinier
>
> > Inferring the definition of "dynamic constraint" from your examples,
> > in the first, I think that it would be sufficient to model and record
> > whatever attribute means "otherwise specified" and include that as
> > part of the condition in the constraint declaration.
>
> What was the constraint part again?
>

I suppose given a db that maintains some temporal dimension for the employee facts ("history table" or somesuch) would have a constraint that the tuples within it must be derived using your expression above. Absent that, the expression itself constrains the values that can be derived. Is that a fair statement?

>
> > I haven't had occasion to apply the technique to anything more complex
> > than such an example, so I'll have to say "I don't know" to the 3D
> > example.
>

Nice sketch of the 3D solution, Bob. I've set aside some time to play with SQL Server's new spatial datatypes (Geography and Geometry), but this cut of the feature only supports 2D.

TroyK Received on Tue Mar 11 2008 - 18:04:46 CET

Original text of this message