Re: Has E/R had a negative impact on db?
Date: Tue, 25 Apr 2006 09:18:53 +0200
Message-ID: <444dcd2f$0$31646$e4fe514c_at_news.xs4all.nl>
dawn wrote:
> mAsterdam wrote:
>
>>Jan Hidders wrote: >>[snip] >> >>>Encapsulation is a nonsensical concept in the context of data >>>modelling. >> >>Yes. Yet, it is a very useful concept in partitioning software. >>It takes some time for software developers to take off that hat >>and get into the data-centric mindset needed to grow a proper >>data-model - that is /if/ they manage to do that.
>
>
> Agreed.
> Since there is no reason to persist the same functions/methods
> repeatedly by keeping data and functions together all the way through
> CRUD functions, there is a point where these need to be decoupled.
What do you mean with "to persist ... functions" or to "to persist ... methods"?
I think the OO perspective makes one look for ways to persist /objects/ - which are supposed to encapsulate data. This is exactly the idea that should be dropped when designing the database because "Encapsulation is a nonsensical concept in the context of data modelling". There is no us vs them here. Designing a database is just a different task than partitioning a piece of software.
> The
> functions defined for a given object are metadata (functions defined
> for a domain).
Only where there is code-data equivalence (e.g. prolog, or the output of compilers) this is true. In the rest of the world it is code.
> Since we often define the same metadata / functions in apps and dbms's,
Putting them on two sides of a slash does not make them the same. Do you have an example of these "metadata/functions" as data?
> we will continue to have those who specify the functions from "each
> side" think their functions are the ones that need to stay packaged
> with the data, with no obvious way to get the db specs into the code or
> the OO methods into the dbms metadata.
>
>
>>Some can't, and >>rely on hibernate or other Object-Relational-Mapping tools >>(unfortunately also abbreviated as ORM,
>
>
> yes, that has confused me more than once
>
>
>>_at_#&$#!)
>
>
> don't forget -- I can read some Dutch
:-)
>>to create >>throw-away software. >> >> >>>It looks a bit as if the problem is more that you are >>>retro-fitting terminology from the world of object-oriented programming >>>into the world of datamodelling that has no place there. ;-)
>
>
> But you do have operations defined on domains in the dbms schema and
> these are tied to attributes. So, we might use other terminology when
> discussing the dbms, but there is some similarity, with the OO side of
> the house often providing more precision in the validations (in
> setters) and more of the functions specific to this domain (dbms
> domains are often specified as varchar with more detailed validations
> in the code to verify that a string is a valid e-mail address, for
> example).
It's other goals and concerns, not just terminology. (BTW I really don't like this idea: "the OO side of the house" vs the other side).
>>>More to >>>the point: it's certainly not an inherent part of modelling with ER >>>dialects.
>
>
> Typing is, however. Cheers! --dawn
>
Received on Tue Apr 25 2006 - 09:18:53 CEST