Re: Declarative constraints in practical terms

Brian Selzer wrote:
> See comments below.
>
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1140733081.318114.74100_at_e56g2000cwe.googlegroups.com...
> > Brian Selzer wrote:
> >> I think you're missing the point. A database is a knowledge repository,
> >> not
> >> an application.
> >
> > It is a portion of one or more software applications, right?
> >
>
> Wrong. It's a separate and distinct entity that is used and manipulated by
> applications.

I was messin' with you, Brian, but I do like my description better ;-)

> >> It is the foundation upon which applications are built.
> >
> > I don't see it that way. I see it as a software component. One could
> > also tip things another direction and say "The UI is the foundation of
> > any software application" or "The processing of data is foundational to
> > any software application." I see these all as components to the
> > greater whole. The design and architecture of software are
> > foundational. I do think that how solid a data model for any aspect of
> > software is has a significant impact on how good the whole is.
> >
> Huh??? Isn't software a synonym for Information System? Isn't the whole
> point of software to manipulate information?

Data processing, yes. Remove either the data or the processing and it is incomplete.

> The user interface is
> arbitrary and at best peripheral to the purpose of an application.

No aspect of software is arbitrary. Any user interface must be a designed component, just as any schema must be. The purpose of a refrigerator is to keep food cold, but the user interface is absolutely critical to the success and usefulness of any refrigerator. The useful refrigerator needs food, cold, and a door. Of course those who engineer the refrigeration think they have designed the entire appliance. (Which reminds me of The Soul of a New Machine when the programmers see that their box has an electrical cord, a case, and such.)

> How
> data is manipulated is important, but depends on the definition of the data.
> Thus the definition of the data is the first and in my opinion the most
> important development task.

I'm pretty close to agreeing with this. I'm very fond of metadata. Agreement on what we are modeling, what problem we are solving, with a software project is a goal of analysis. How we go about trawling for such and coming to a common understanding about the definition of the data might vary by project and project team, however. I think that prototypes (that need not have a real dbms backing them) are often a good way to shake out the requirements for a project.

> Before you can even begin the process of design and architecture, you must
> first perform a thorough analysis, and the ultimate purpose of that analysis
> is to determine what information needs to be collected and retained.
>
> >.... I do think that how solid a data model for any aspect of
> > software is has a significant impact on how good the whole is.
> >
>
> I'm glad you do. The first time I read this passage, I thought you meant
> "don't."

No, no. I really do care a lot about developing very solid data models.

> > eliminating it in some places and introducing it in others
> >
> I disagree. The definition of a database should be all that is required to
> determine whether a database value is legal. Constraints are an integral
> part of that definition.

I agree they are integral to the solution. At this point I'm not sold that they must be defined to any particular piece of software, such as the dbms, but I'm understanding that position better. <snip>

> > How do you know that once mapped and indexed, queries are easier and
> > faster? There are no benchmarks of which I am aware that are data
> > model independent for database performance. As for easier, I find it
> > easier to write
> >
> > select name, gpa from students where every major <> "math"
> >
> > (converted from a non-1NF query language into pseudo-SQL) than the
> > equivalent sql-92 statement
> >
>
> How do I know? Experience and just plain common sense.

I'm guessing it is only the latter you are employing. Have you really used a database that supports queries where there are list attributes? Have you done comparisons?

> A list must be
> traversed sequentially. A set or bag must be scanned. Indexes make queries
> against these much, much faster.

I'm certain there are pros and cons to these different approaches. I have not found any performance benchmarks that permit non-SQL databases to be compared to SQL-DBMS's (although there might be some -- let me know if you know of any). I've seen zippy quick performance from both (1NF and non-1NF) and dog-slow performance from both.

<snip>
> The whole point of software is to manipulate information. All other aspects
> of software development depend on the definition of that information--that
> is, the database schema: you have to know what you're manipulating before
> you can manipulate it. I would think that that makes the database the
> foundation upon which applications are built.

I would definitely say that the logical data models employed in the software are integral to the software and the success of the software. In addition, you need to have a means to persist data, a means to display data, a means of communicating data every which way. Data & processing are the two essential components of data processing. Cheers! --dawn Received on Sat Feb 25 2006 - 03:20:42 CET