Re: Declarative constraints in practical terms
Date: 24 Feb 2006 20:26:17 -0800
Message-ID: <1140841577.194541.143460_at_v46g2000cwv.googlegroups.com>
Brian Selzer wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1140834041.969249.302190_at_v46g2000cwv.googlegroups.com...
> > 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:
<snip>
> > Data processing, yes. Remove either the data or the processing and it
> > is incomplete.
>
> But there's a one to many relationship between a database and the
> applications that manipulate it. If the database is not self-contained, and
> by that I mean able to maintain its own integrity, then the code required to
> maintain that integrity must be duplicated in every application. I guess
> you could argue that a framework that wraps the database is actually part of
> the database, and I might be inclined to agree--at least in principle, but
> only if that framework is available for use by the database (for use in
> triggers and declarative constraints) and only if there is no way to bypass
> it.
> >
> >> 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.)
> >
> I disagree. According to Webster, arbitrary: based on or determined by
> individual preference or convenience rather than by necessity or the
> intrinsic nature of something. I can build a user interface using web
> pages, windows forms, green screens, etc. I can decide to collect
> information on one screen or a series of screens. Yet all of these designs
> achieve the same goal, which is to collect and display information. The
> design of a user interface depends on the individual preference of the
> software architect, whereas the definition of the information that must be
> collected or displayed is determined only by what is necessary to fulfill
> the purpose of the application.
Then it might surprise you that I was once involved in a project where the goal was to have reports that could be pointed at any database, whether an SQL data source or others (determined in advance). The data structures, not just the data sources, were different. The interface to the user (the reports) needed to work over time and independent of choice of database or even data model.
I'm OK with data-centric thinking, as long as it is not completely stuck there, but database-centric thinking doesn't resonate with me any more than UI-centric or EDI-centric thinking.
>> > good way to shake out the requirements for a project.
> >> 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
> >
>
> I agree, but you don't deliver prototypes.
There is an industry rule that came about after the abuses of the 70's that says that you don't evolve prototypes. I agree you don't deliver them, but there are times when you can do well to evolve them to deliverable software.
> >> 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.
> >
>
> Why do you even need benchmarks? Just use common sense. If you have 1000
> elements in an ordered list, it will take on average 500 compares to find
> the first matching element,
Not if all logical lists are also physically ordered. (Yes, I know there are tradeoffs)
> whereas with an index it will take at most 10.
> To find all matches, it will take 1000 compares if the list isn't ordered,
> whereas with an index it will take at most 10 + the number of matches.
Other common sense might tell you that if all properties, including list properties, are included in a single read, you don't have to perform multiple reads to get the attributes related to a single entity. Those who really know about performance can provide sound reasoning better than I can for why IBM UniVerse, for example, is very scalable and very fast. Until you actually see something else using some other model, I suggest that you not trust your common sense entirely on this one.
Cheers! --dawn Received on Sat Feb 25 2006 - 05:26:17 CET