Re: O/R Mapper

Joanna Carter [TeamB] wrote:

> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xxxxxxxxx> a écrit dans
> le message de news: xn0eh6pwmd80mm000@xxxxxxxxxxxxxxxxxxxxx
>
> > what the definition of 'best' is in your statement is still vague.
>
> I did not state that my OPF was the best, just that deriving classes
> from tables was not the best. Unfortunately, unitl we get a "perfect"
> OODB, we will all be working with compromise due to the impedance
> mismatch between the two paradigms.

Well, if you follow this analogy:
- create NIAM model from reality
- create E/R model from niam model
- create tables from E/R model

- create entity types back from tables,

you get back your e/r model. With the proper tooling you get back the
niam model from the reverse engineered e/r model.

The advantage is that you can use NIAM/ORM for functional analysis and
also use the results of that for the db schema, which results in a
relational model build on entity definitions, which are also the base
of what you will work with when you reverse engineer it. At the same
time you have the freedom to adjust the entity definitions in your
classes to the application, without jeopardizing the route from
functional research + abstract model -> e/r model -> tables.

In a lot of organisations, this is a proper way of designing the
database, often done by a person who's job it is to design the
schemas/maintain the schemas because that person is the specialist for
relational models. Although I'd love to say that programs can do that
job for that person, it's often a lot of 'interpretation' of the
reality to come to the proper result.

> > But, tell me: why is this 'better' ? Of course wacky setups are
> > thinkable where there are clear differences, the question is if
> > this will bring you any advantage.
>
> Because this is an accurate modelling of the real compositional
> nature of such classes; it is not abstracted to "make it fit" a
> relational database.

though neither would the other way around.

> > Btw I was referring to the model you proposed: add fields /
> > hierarchy elements to classes and let a tool propagate the changes
> > to the db. (which you seem to declare 'best'). The propagation of
> > changes to the db can be cumbersome in a huge schema with lots of
> > data.
>
> As I have already said, I did not say that this method was "the
> best", just that it avoids having an object model coerced into a
> relational one.

yeah well, if you start with the classes and create teh relational
model from that, you of course cut corners to make it as easy as
possible for the classes to get persisted and let the o/r mapper do its
job, which will compromise what otherwise would have been a solid
relational model.

It's hard, but doable to reproduce an abstract model of entities
which aren't 1:1 copies of table definitions, and which are also usable
in hierarchies for example (supertype/subtype) which already move away
from the relational approach as inheritance isn't modelable in a
relational model without semantic interpretation of the relational
model and / or containing data.

> > So, your 'superior' mapper always cranks out the proper upgrade
> > scripts, and takes into account the full load of the db ?
> > Remember: you claimed starting with classes and let the o/r mapper
> > update the db according to the changes made to the class model be
> > 'best'. So, 'not true', what does that really mean?
>
> We don't write migration scripts, the OPF looks after that for us;
> since we wrote the scripting engine.

Though how a production database is migrated is often depending on the
amount of data in the tables, not the structure of the tables itself,
and because a production database with a lot of data is hard to backup
/ restore easily, migrating these databases can be a task which is
often done by hand, tested in labs first etc.

> Our OPF evaluates execution times and attempts to optimise the
> generated SQL; if it still can't achieve desired speeds, then we have
> a facility for injecting a custom generator for any given type.

Clever.

> Most complex data retrieval that would require joins, etc tends to be
> for what I would call reporting classes. IOW, they are complex
> queries for something like, how many of a certain product were sold
> to Mr Bloggs in 2004. For these scenarios, we write a class like
> ProductSalesSummary and ensure that the OPF contains a custom query,
> handcrafted if necessary.

I do similar things: you can define a list based on fields in the
entities in the project (which support inheritance) which are related,
and you can also do that in code, dynamically. Using the compile-time
checked query language then to build the query with aggregates, groupby
etc. for reporting data.

Not a lot of the o/r mappers out there offer that kind of features, as
most of them use the entity as their smallest block to work with, while
if they would use teh attribute (entity field), dynamic lists and the
like would be possible.

> I am not saying that your design doesn't have value; it certainly
> makes a quick migration for legacy databases but for new-build
> projects, we have found the object-led approach works very well.

I also think what is the core information provider for your design is
important. If you, as I stated above, use NIAM/ORM or similar highly
abstract modelling technique to design the reality with the customer
during the functional research phase, you have other sources of
information than when you start with a UML model. It's not that the
other way of doing things doesn't work or works less good, it's just
that a person should realize that by starting with the DB requires a
properly designed relational model, and starting with classes requires
a properly designed class model. If people don;t realize that, no
matter what technique they choose, it will be cumbersome.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: Databinding - Best Practice (object-oriented)
    ... And it is infinitely better for data management BTW. OO designers ... should learn about The Relational Model, but many of them only know ... OO is for application development only, not for Database Systems ... The design of the whole system is very different from the design of ...
    (microsoft.public.dotnet.framework.windowsforms.databinding)
  • Re: Databinding - Best Practice (object-oriented)
    ... And it is infinitely better for data management BTW. OO designers ... should learn about The Relational Model, but many of them only know ... OO is for application development only, not for Database Systems ... The design of the whole system is very different from the design of ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Data Layer architecture
    ... > the first week of>> any serious database course). ... rules were described to be inside the RDBMS, ... is not a theory which states anything about business ... > The Relational Model is nothing but a direct application of set theory ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Table Design Question
    ... > requires more than two probes, no matter how large the database. ... > acceptable (in the relational model) to have an Identity attribute to ... the gap in the sequence is not filled in and the sequence ... > vin CHARNOT NULL REFERENCES Motorpool); ...
    (microsoft.public.sqlserver.programming)
  • Re: SQL
    ... >business and presentation rules in the applications. ... DBMS were created ... The fundamental purpose of a DataBase Management ... >Around a corruption of THE Relational Model. ...
    (comp.object)