Re: Declarative constraints in practical terms
Date: Sat, 25 Feb 2006 04:01:03 GMT
Message-ID: <3EQLf.35102$Jd.31579_at_newssvr25.news.prodigy.net>
"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:
>> >> 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.
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.
>> 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.
>
I agree, but you don't deliver prototypes.
>> 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, 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.
> <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 - 05:01:03 CET