Re: Decouple SQL queries from class in OOP design

"frebe" <fredrik_bertilsson@xxxxxxxxxxx> writes:
> > Again, not all databases have a single owner. Shared and
> > enterprise databases are quite common.
>
> Common, but stupid.

That view is . . . exceedingly uncommon in my experience. Large,
distributed, enterprise systems must share information among thier
components. A significant portion of the effort expended in a typical
EAI project deals with enabling the sharing of data. Are you really
asserting that a database instance should have only one client?

> > Denormalization for performance is a change I've seen on more than
> > one occasion.
>
> Of you denormalize a set of tables for performance, I assume that
> the original normalized tables are still there and are the master
> for the data.

Not necessarily. Certainly not in the situations where I've seen
it done.

> Otherwise you have created yourself a hell.

The tradeoff was a significant performance improvement in
exchange for more complexity in maintaining referential integrity. I
wasn't the one who made the call and I may even have chosen
differently had it been my responsibility, but the decision was
logically supportable.

> > If the new schema provides the same information in a different
> > way, only the implementation of the component or service providing
> > the business functionality need change.
>
> Please give some example. Why would you change the schema if it
> still provides the same information? It like rewriting your classes,
> but the still do the same thing.

That's called refactoring and it is done to improve the
maintainability and extensibility of the code. The same can apply to
database schemas. The most recent time I've seen it done was to
better support a planned system that could benefit from inheritance
being modeled differently.

> > DBAs may also change the schema to support other applications, for
> > example by moving some columns from one table to a new table in
> > order to change a 1:1 relationship to a 1:M. Such changes are not
> > uncommon in large integrated systems
>
> Chaning a 1:1 relationship to a 1:M will not change your business
> logic?? Please give some example.

Consider something as simple as allowing a customer to have more
than one phone number. If the existing applications don't need more
than one, having them decoupled from the schema means that the change
can be made in exactly one location. Even if the existing
applications must be extended to include support for multiple phone
numbers, having them decoupled from the schema allows them to be
migrated incrementally rather than in one high risk, resource
intensive big bang.

> > A particular schema is an implementation detail.
>
> Everything may be considered as an "implementation detail" in some
> context. But in the context we are talking about, the database
> schema is an interface.

We may be differing on definition. What do you mean by
"interface"? The schema and SQL are a means for accessing the data,
subject to some integrity rules enforced by the DBMS. Interpretation
of that data is up to the application. An interface, in this context,
would provide additional semantic abstraction.

> > The same functionality can be supported by a variety of schemas,
> > more than one of which can be in third normal form.
>
> The same fact applies to your service interfaces. Two different
> interfaces may provide the same functionality. But we still not need
> to decouple our application from the service interface.

Actually, I spend a lot of my time doing just that. Most of the
systems I've worked on in the past three years are based on
service-oriented architectures (SOAs). Jini, for example, decouples
clients and services, and allows services to be accessed through
multiple interfaces, if appropriate. It makes for very scalable,
resilient, and extensible systems.

> > I've provided a few examples of the types of schema changes that
> > occur in real systems.
>
> You have still not provided a single example.

That claim is more than a little disingenuous, considering you
just replied to two of my examples.

> > Changes to business rules are far from the only reason for schema
> > changes.
>
> Changes to business rules are by far the most common reason for
> schema changes.

That may be the case in your experience, but large enterprise
databases are subject to a wide variety of pressures. In any case,
your assertion does not contradict mine.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, CORBA, UML)
.

Relevant Pages

  • RE: Inconsistent Schema Versions
    ... on the existing server, to try to force it to upgrade to the same version. ... Microsoft MSDN Online Support Lead ... Subject: Inconsistent Schema Versions ... The schema version of the database ...
    (microsoft.public.sharepoint.portalserver.development)
  • RE: linq combined query
    ... In order to reproduce the issue, we need to create a database with the same ... Could you please paste your database schema if it's possible for you? ... Microsoft Online Community Support ... where an initial response from the community or a Microsoft Support ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Java is becoming the new Cobol
    ... In the Unisys 2200 environment using their Network Database Server, you get a schema work area depending on how you invoke the schema. ... However, it not only copies the schema area into the program, but the "DMCA" (Database Management Communication Area - basically, the block of information that holds your connection state) is copied in too. ... So, you're left with working-storage, which makes it visible to your program only, or common-storage, which makes it visible to programs linked in. ...
    (comp.lang.cobol)
  • RE: Schema data in VB.Net 2005
    ... I think that you referred to using ADO.NET to get schema data from an ODBC ... you can get schema information of a database by two methods ... Microsoft Online Community Support ... or a Microsoft Support Engineer within 1 business day is acceptable. ...
    (microsoft.public.data.odbc)
  • Split messages
    ... This is based off the northwind database. ... Create document schema: ... Select the SQL entry, make sure that we are pointing to the SQL ... For the item select a receive pipeline and name it EmpSplitPipe.btp. ...
    (microsoft.public.biztalk.general)