Re: MV Keys

From: dawn <dawnwolthuis_at_gmail.com>
Date: 3 Mar 2006 16:36:13 -0800
Message-ID: <1141432573.168443.57560_at_u72g2000cwu.googlegroups.com>


Bob Hairgrove wrote:
> On 3 Mar 2006 05:49:52 -0800, "dawn" <dawnwolthuis_at_gmail.com> wrote:
>
> >This issue of minimizing complexity is confusing. A logical data model
> >is implemented by developers using an interface to a dbms. There are
> >trade-offs in any design, of course, and if we are going to build a
> >house with round walls it will cost additional dollars. But we don't
> >want dbms tool designers to suggest they will be making design
> >decisions based on simplifying the design for the computer or for the
> >dbms developers. The simplicity we need to care about a bit more is
> >the simplicity for the user of the tools. I think that is where
> >Marshall's use of the term "power" comes in. Surely you can implement
> >a list, for example, using the RM, but the tool is not doing much work
> >for you. It doesn't have enough power. It isn't simple enough from a
> >user standpoint.
>
> The RM ("relational model") is not a tool -- it is a model,

Models are tools of the trade for me. I suspect this is a definition issue, not a real difference of opinion.

> just as
> the name says it is. Of course, the finest database does nothing until
> some application *uses* it.

Yes, a database would not be production software without having a means for data to get in and out. A database is part of one or more solutions, not one we can lop off as an entity unto itself.

> The fact that applications can reside in
> the database itself in the form of scheduled jobs which run stored
> procedures, etc. shouldn't blur the distinction between the two
> ("application != database" ... say this 120 times every day when you
> get up in the morning, then maybe you will see things a little
> clearer).

Applications include one or more databases as components of an overall solution. Databases can be incorporated into one or more applications.  Does that cover it for you? If not, what is inaccurate?

> The RM is a model for storage and manipulation of data which can be
> used by very many different applications, and the applications need
> not know anything about each other.

Agreed.

> That is the beauty, and the
> strength, of the concept. It is up to the application to provide an
> interface to the user which is easy to use; this shouldn't be a
> requirement of the database!

Agreed.

> In most respects, the duty of a good
> database design is to *protect the data* from abuse by misinformed
> users (and I include application developers here as well).

The duties of good software development, whether a database component or any other, include mitigating risks, facilitating quality data, etc.  I'll agree it is important to protect data integrity and that we need to take appropriate measures to mitigate risks that anyone on the project team, whether someone writing application code, database constraints or anything else, would corrupt the data.

When it comes to software projects, a team is likely more productive if all software development resources, including people who make changes to the database schema and constraints, those who do software builds, etc are on the same project team, with cross-training, working for the same project leader. Some sites are organized to have "teams trying to do projects" and "teams trying to inhibit projects" using bureaucracy, for example. Checks and balances are good, policing with "keepers of the gate" is an overrated strategy IMO.

> A good database design is usually never "simple enough" to the average
> user. But it really doesn't matter because "simple" shouldn't be a
> requirement for database design.

As simple as possible, but no simpler, right?

> At best, it might serve as a
> requirement for a user interface design.

I'm asking that people think of the API or language used for working with a database and its schema as a "user interface" too. If those working on DBMS software see software developers as their users, I suspect we can improve both productivity and quality of all aspects of the resulting software.

I know I'm saying this with a programmer's hat on, but I think we need to move more in that direction. I know how to think about it from a "we must protect the database and those programmers are requesting changes that will muck it up" viewpoint too, but I figure this group already has too much of that perspective already. Cheers! --dawn Received on Sat Mar 04 2006 - 01:36:13 CET

Original text of this message