Re: MV Keys

Bob Hairgrove wrote:
On 3 Mar 2006 05:49:52 -0800, "dawn" <dawnwolthuis@xxxxxxxxx> 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

.

Relevant Pages

  • Re: File-System or DBMS? (non-flammable clothing optional)
    ... didn't know how to design a database." ... I, too, think that it is not a good design to ... writing sentences with lists within lists is not common, ... Once Pick was the operating system, and you can't get much more DBMS than ...
    (comp.databases.pick)
  • Re: File-System or DBMS? (non-flammable clothing optional)
    ... didn't know how to design a database." ... Once Pick was the operating system, and you can't get much more DBMS than ... Certainly, the all provide the tools, utiliies and means to design, store ... I'll bet frosty prefers any flavor of MV over anything else ...
    (comp.databases.pick)
  • Re: MV Keys
    ... is implemented by developers using an interface to a dbms. ... want dbms tool designers to suggest they will be making design ...
    (comp.databases.theory)
  • Re: Combining tables - UNUSUAL REQUEST
    ... It's not an unusual request at all. ... developers to realize that their original table design needs some refinement ... in order to accommodate the needs of the growing database application. ... That's how database developers get "experience." ...
    (microsoft.public.access.tablesdbdesign)
  • Re: MV Keys
    ... is implemented by developers using an interface to a dbms. ... want dbms tool designers to suggest they will be making design ... The simplicity we need to care about a bit more is ...
    (comp.databases.theory)