Re: MV Keys

On 3 Mar 2006 16:36:13 -0800, "dawn" <dawnwolthuis_at_gmail.com> wrote:

>Bob Hairgrove wrote:
[lots snipped...]

>> 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.

Not the database as a whole, but the particular view, or perspective of the data as seen by any one solution. There is a big difference.

>> 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.

No, they include their particular views of the data, not the database itself.

>Databases can be incorporated into one or more applications.
> Does that cover it for you? If not, what is inaccurate?

The fact that one database can be used by different applications with different priorities, objectives and constraints means that the model cannot cater to one application or the other in an effort to reduce complexity. This is why most applications which use some RDBMS today will typically only see views of the data specific to that application and not work directly with the tables. An application need not know, for example, that the data they see in a certain column is actually calculated on the fly by a function in the database. The same goes for related lists which are easy to generate from a normalized schema. The opposite might hold true for one application, but not for another. Therefore, we normalize the tables to provide for a consistent handling of the data by many different applications.

>> 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.

You agree that it shouldn't be a requirement of the database? Then why did you say:

>"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."

It sure sounds to me like you are criticizing the RM for not being simple enough for users...

>> 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.

I agree 100% that communication between the teams is of utmost importance. During the Swiss census, we had a situation where the DBA's removed a column from a table and didn't tell everyone about it, or somehow the information didn't make it through all the channels. There was at least one application which broke because of it. Also, some of my code in stored procedures worked at the office and failed when we delivered for them to sign off on it because someone had added a NOT NULL constraint to a column I didn't know about, and the reference db at work, which was supposed to be an exact clone of the real db, obviously wasn't up to date.

But these are all *management* issues which have nothing to do with the RM per se. Although such incidents are unfortunate, they could just as easily have happened with some other database model. Also, any antagonisms which arise between DBA's and application developers are management or personnel issues. Why do DBA's implement audit trails, for example? Do you think that every user and application developer should know (a) that audits are in place, (b) the tables where the audit data is stored, and (c) passwords to gain read/write access to that data? Surely not! Some things should remain hidden from all but the sysadmin.

>> 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?

Yes.

>> 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

As you can see, I have also been on the other side of the fence. It has nothing to do with the model itself, but everything to do with management and attitudes, as well as a lack of understanding of what is important on both sides of the fence.

--
Bob Hairgrove
NoSpamPlease_at_Home.com