Re: Order & meaning in a proposition

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c517ks$lal$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:I1Scc.51787$_37.3056_at_newssvr16.news.prodigy.com...
> > "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > news:c4vdsj$n7k$1_at_news.netins.net...
> > > Bingo - I'm referring to stuff that no one would consider "important
> > enough"
> > > from a data processing standpoint, but still provides information that
> > need
> > > not be lost (in all cases). Why lose ordering if you don't have to?
> >
> > Why leave its importance implicit (e.g. to be used or ignored, but in
> either
> > case ASSUMED by application developers) if you don't have to?
>
> The information of which I speak (and my example is not great) is that
which
> we would recognize as insignificant and when we ask the user, to be
certain
> we are making correct assumptions, they will acknowledge the data as
> unimportant. In fact, it is not important, it is just a little more
> information that could perhaps seep into our brains and help us solve a
> business problem better, unwittingly. I recognize that by turning
sentences
> into data to which we will apply predicate logic, we are losing some of
this
> "fruffy" information. But, if we don't lose anything from a logic
> perspective in keeping such things as the ordering of multiple nouns in a
> sentence, then let's not.

But there is a big difference between a list or array and a set. Are your multivalued attributes really sets ordered by data entry sequence? If so, that's a data structure we should perhaps know something more about. And if it's not a set, but a list, then it's important for counts that the app know that.

I'm not necessarily disagreeing with you - just pondering the implications of a novel new (?) data structure.

> For example, if there are strict rules at the pizz place (yes, that is
> another thread) that we put mozzarella on before we put parmesan on the
> pizza and when the order pops up it says
>
> Pizza Mozzarella
> Parmesan
>
> Then that helps us in some little bit, even though it is redundant
> information. It wouldn't be worth collecting this information
specifically
> in some sort of ordering data element, but if we pop this puppy into the
> database and it keeps the order that we stated it in, so much the better,
> right?

One benefit of a set is that a DBMS implementation can do what it likes, and for optimization, order can be significant. Furthermore, I do think it's important to distinguish what data structure you really mean. Depends on the answer to the above question I asked.

> > I disagree completely. A relational structure allows the simple
generation
> > of any number of hierarchies, without favoring one. Unless you enjoy
> > coupling the internals of your app to every communication it has to make
> > with the outside world, that's a Good Thing (tm 2004, Martha Stewart
> Inc.).
>
> This reminds me of some new customers to a UniData (an IBM PICK database)
> application who told me that they would like to use ODBC to retrieve their
> data for an XML document. I pointed out to them that the UniData data had
> information such as a student and their "set of majors" (whether stored
that
> way or virtual data) so you could ask it to
>
> LIST STUDENTS MAJORS
>
> and you would get one record for each student, with their list of majors.
>
> If you then use ODBC to access it, you are doing a virtual normalization
of
> the data, then you are taking that data and mapping it to XML, where, in
> this case, they needed one document per student (I'm truncating the
example
> for simplicity purposes).
>
> Similarly, we can take what is in our brain as a statement about David
> majoring in Math and Philosophy and turn that into two propositions about
> David prior to designing the schema for a PICK database where we would
then
> pour those two statements back together. But why go through that silly
> exercise?

For the benefit of other queries. Yes, if all you're ever doing is displaying that proposition about David, then fine. But I've yet to see such an app that wouldn't want to say something (for example) about counts within majors (or some other grouping that requires an inversion of the nesting you propose), and then you have much more work.

In short: my users have always been able to surprise me in the queries, reports, and additional apps they want. A normalized (non-1NF) structure has always been my friend in this record. And my Java development has led me to further loathe the enforced nesting of "Entity A" inside "Entity B" - you can have the nesting both ways (e.g. use a graph), but that path is fraught with bugs.

> Skip the 1NF in the process and you can go "from your brain to
> your data structure" even without a lot of theory classes in between.

For prototyping that would be a good idea - to help narrow down the requirements. I just wouldn't want to gamble my data structures and queries on one particular nesting.

> And then the translation to XML is quite obvious too. Get SQL, ODBC, and
the
> relational 1NF, uh, hogwash out of the middle -- it only makes for extra
> steps. --dawn

And doing a report of, say, students listed beneath their majors wouldn't require much work if you've nested majors inside students? Or perhaps listing students and the prereqs for a major, which would then require that "major" be a first-class "entity"?

I've never found the "additional work" to be onerous.

• erk