Re: [pilot-db-list] record display/layout hints

[<pef...@fe...>]

On Mon, 5 Nov 2001, Scott Wallace wrote:

> If you do this, then essentially you have 2 completely distinct record
> structures, one for the "Foo" class and one for the "Bar" class.  This

Yes, exactly.

> means that each record is big enough to hold data for both classes, but
> only a small subset of these fields are actually used.  This would
> be more of a problem as the number of classes gets bigger.

But for my purposes, it's possible (and in fact, likely) that both Foo
and Bar will be filled in for a given record. Perhaps I should describe
my intended application. :)  I'm trying to replace paper forms that an
agent in the field will fill out with a database on a Palm. Currently
the agent fills out the paper form, drives it back to the office, and
transcribes it by hand into a PC. The idea is to hotsync it rather than
transcribing by hand, and to have records of previous forms without
carrying around a box of paper.

So, with that in mind, each field in the paper form is unique and may be
filled out along with any other field. That is, there may be "Foo"
components and "Bar" components for a single form, each with its own
distinct set of attributes. I don't necessarily care that the attributes
are named the same thing; however, I have to deal with the fact that
sometimes they are, which would create ambiguities in the field names.
If it just says "Attrib3," then which one is it? So you want to use an
unambiguous name, like "Foo Attrib3". However, this makes the UI klunky
since your screen space is very limited. You can't use the concept of
visual context to know that Attrib3 belongs to Foo (because it's right
under the Foo heading, say). That's the problem that I want to solve.

> Why wouldn't you make 2 databases?  This would really cut down on the
> wasted space. One db would define the "Foo" class and another
> the "Bar" class.  Then you could figure out some way to view them
> together....?

I considered that, but discarded it as too complex. I could have a "Foo"
database where each row in the database corresponded to a row in the
"main" database. Keeping those in sync seems like it would be a lot of
trouble.

-Peff