Good user friendly custom fields terminology? 
Author Message
 Good user friendly custom fields terminology?

Folks

I need to setup a flexible table where the customer fills in both the
Label and the textbox.  For example some customers might want to
describe their units right down to automatic transmission serial
number, engine serial number while others want to use colour, Alberta
license plate, Saskatchewan license plate and cell phone number.

So the obvious solution is to have a "definition" table for the left
hand side which the customer fills out in a system wide table and then
for each unit the "definition" appears in combo boxes on the LHS and
they fill in the appropriate data on the RHS.

So what is good user friendly terminology?

Quickbooks uses the term "Custom Fields".  In the definition screens
they call the field a Label.  In the unit screens they don't give the
RHS a heading.    I was thinking in terms of "data"

So the heading for each one clients unit would look something like

"Custom Fields"  (in bold 12 point)
Label                           Data
Colour                  Blue
Alta license plate      ABC 123
Sask license plate      DEF 456
Cell number             871 1234
(above are combo boxes)

While another clients unit would look like
"Custom Fields"  (in bold 12 point)
Label                           Data
Engine serial Number    abc123456456
{*filter*} serial number    abc3455095
Tire Size               something

I trust this makes sense.

Comments please.

Tony
----
Message posted to newsgroup and emailed.
Tony Toews, Independent Computer Consultant
The Year 2000 crisis: Will my parents or your grand parents still be receiving
their pension in January, 2000?  See http://www.***.com/
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.***.com/



Mon, 11 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

Hi Tony,

If I get the drift of what you're doing. You are building a customer defined
lookup table for the "label". If that's it. Custom fields and data are OK,
but you might want to also consider "Optional Fields" and "Input Value" or
"Data Input". I think everyone understands the term input, and term optional
doesn't give the user a sense of "Jeez, What do I do now? Do I need to use
them all?"

Just my 2
-----
Arvin Meyer


Quote:
>Folks

>I need to setup a flexible table where the customer fills in both the
>Label and the textbox.  For example some customers might want to
>describe their units right down to automatic transmission serial
>number, engine serial number while others want to use colour, Alberta
>license plate, Saskatchewan license plate and cell phone number.

>So the obvious solution is to have a "definition" table for the left
>hand side which the customer fills out in a system wide table and then
>for each unit the "definition" appears in combo boxes on the LHS and
>they fill in the appropriate data on the RHS.

>So what is good user friendly terminology?

>Quickbooks uses the term "Custom Fields".  In the definition screens
>they call the field a Label.  In the unit screens they don't give the
>RHS a heading.    I was thinking in terms of "data"

>So the heading for each one clients unit would look something like

>"Custom Fields"  (in bold 12 point)
>Label                       Data
>Colour Blue
>Alta license plate ABC 123
>Sask license plate DEF 456
>Cell number 871 1234
>(above are combo boxes)

>While another clients unit would look like
>"Custom Fields"  (in bold 12 point)
>Label                       Data
>Engine serial Number abc123456456
>{*filter*} serial number abc3455095
>Tire Size something

>I trust this makes sense.

>Comments please.

>Tony
>----
>Message posted to newsgroup and emailed.
>Tony Toews, Independent Computer Consultant
>The Year 2000 crisis: Will my parents or your grand parents still be
receiving
>their pension in January, 2000?  See http://www.***.com/
>Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.***.com/



Mon, 11 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Tony,

Just a little quibble (you know you can depend on me <g>)...

I'd use "Value" rather than "Data".  "Data" is incorrect, as it is the
plural form of the word.  And "Datum" is simply too ugly to be contemplated.

FWIW,

    - Rebecca.


Quote:
>Folks

>I need to setup a flexible table where the customer fills in both the
>Label and the textbox.  For example some customers might want to
>describe their units right down to automatic transmission serial
>number, engine serial number while others want to use colour, Alberta
>license plate, Saskatchewan license plate and cell phone number.

>So the obvious solution is to have a "definition" table for the left
>hand side which the customer fills out in a system wide table and then
>for each unit the "definition" appears in combo boxes on the LHS and
>they fill in the appropriate data on the RHS.

>So what is good user friendly terminology?

>Quickbooks uses the term "Custom Fields".  In the definition screens
>they call the field a Label.  In the unit screens they don't give the
>RHS a heading.    I was thinking in terms of "data"

>So the heading for each one clients unit would look something like

>"Custom Fields"  (in bold 12 point)
>Label                       Data
>Colour Blue
>Alta license plate ABC 123
>Sask license plate DEF 456
>Cell number 871 1234
>(above are combo boxes)

>While another clients unit would look like
>"Custom Fields"  (in bold 12 point)
>Label                       Data
>Engine serial Number abc123456456
>{*filter*} serial number abc3455095
>Tire Size something

>I trust this makes sense.

>Comments please.

>Tony
>----
>Message posted to newsgroup and emailed.
>Tony Toews, Independent Computer Consultant
>The Year 2000 crisis: Will my parents or your grand parents still be
receiving
>their pension in January, 2000?  See http://www.***.com/
>Microsoft Access Links, Hints, Tips & Accounting Systems at
> http://www.***.com/



Sat, 16 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

Quote:

>Tony,

>Just a little quibble (you know you can depend on me <g>)...

>I'd use "Value" rather than "Data".  "Data" is incorrect, as it is the
>plural form of the word.  And "Datum" is simply too ugly to be contemplated.

     "data" is often used as a collective noun.  Besides, in the
examples:
Quote:
>>"Custom Fields"  (in bold 12 point)
>>Label                       Data
>>Colour Blue
>>Alta license plate ABC 123
>>Sask license plate DEF 456
>>Cell number 871 1234
>>(above are combo boxes)

>>While another clients unit would look like
>>"Custom Fields"  (in bold 12 point)
>>Label                       Data
>>Engine serial Number abc123456456
>>{*filter*} serial number abc3455095
>>Tire Size something

there is more than one datum.  Yes, indeed, there are many *data
values*!

[snipped previous]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.



Sat, 16 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Um...

A "collective noun" is a singular word form used to represent a multiple
entity.  There is some dialectical variation in verb usage (in Australian
english, one says "the company are announcing record profits", which always
sounds odd to my American ear, for example), but to the best of my knowledge
(and the reference books I have to hand), plural noun forms are never
collective.  It may very well be, as you say, common usage.  That does not
make it correct.

In any event, if Tony _were_ to use "Data", he would have to use "Labels"
for the sake of consistency.

I suppose the form used for attribute names is a somewhat arbitrary
decision.  I use the singular form, since I have found it less confusing for
the users.  No one is confused by a list of names with the heading
"Surname".  Most people, I think, would be confused by a text field with the
caption "Surnames".  (Think of swapping back and forth between datasheet and
form view in Access.)

When I grow up and they make me god, I might require that everybody use the
singular form for attribute names, but until then, you are of course free to
use whatever form you like with nary a peep from me.  I will complain,
however, if you're not consistent.

    - Rebecca


Quote:

>>Tony,

>>Just a little quibble (you know you can depend on me <g>)...

>>I'd use "Value" rather than "Data".  "Data" is incorrect, as it is the
>>plural form of the word.  And "Datum" is simply too ugly to be
contemplated.

>     "data" is often used as a collective noun.  Besides, in the
>examples:
>>>"Custom Fields"  (in bold 12 point)
>>>Label                       Data
>>>Colour Blue
>>>Alta license plate ABC 123
>>>Sask license plate DEF 456
>>>Cell number 871 1234
>>>(above are combo boxes)

>>>While another clients unit would look like
>>>"Custom Fields"  (in bold 12 point)
>>>Label                       Data
>>>Engine serial Number abc123456456
>>>{*filter*} serial number abc3455095
>>>Tire Size something
>there is more than one datum.  Yes, indeed, there are many *data
>values*!

>[snipped previous]

>Sincerely,

>Gene Wirchenko

>Computerese Irregular Verb Conjugation:
>     I have preferences.
>     You have biases.
>     He/She has prejudices.



Sun, 17 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Um...

A "collective noun" is a singular word form used to represent a multiple
entity.  There is some dialectical variation in verb usage (in Australian
english, one says "the company are announcing record profits", which always
sounds odd to my American ear, for example), but to the best of my knowledge
(and the reference books I have to hand), plural noun forms are never
collective.  It may very well be, as you say, common usage.  That does not
make it correct.

In any event, if Tony _were_ to use "Data", he would have to use "Labels"
for the sake of consistency.

I suppose the form used for attribute names is a somewhat arbitrary
decision.  I use the singular form, since I have found it less confusing for
the users.  No one is confused by a list of names with the heading
"Surname".  Most people, I think, would be confused by a text field with the
caption "Surnames".  (Think of swapping back and forth between datasheet and
form view in Access.)

When I grow up and they make me god, I might require that everybody use the
singular form for attribute names, but until then, you are of course free to
use whatever form you like with nary a peep from me.  I will complain,
however, if you're not consistent.

    - Rebecca


Quote:

>>Tony,

>>Just a little quibble (you know you can depend on me <g>)...

>>I'd use "Value" rather than "Data".  "Data" is incorrect, as it is the
>>plural form of the word.  And "Datum" is simply too ugly to be
contemplated.

>     "data" is often used as a collective noun.  Besides, in the
>examples:
>>>"Custom Fields"  (in bold 12 point)
>>>Label                       Data
>>>Colour Blue
>>>Alta license plate ABC 123
>>>Sask license plate DEF 456
>>>Cell number 871 1234
>>>(above are combo boxes)

>>>While another clients unit would look like
>>>"Custom Fields"  (in bold 12 point)
>>>Label                       Data
>>>Engine serial Number abc123456456
>>>{*filter*} serial number abc3455095
>>>Tire Size something
>there is more than one datum.  Yes, indeed, there are many *data
>values*!

>[snipped previous]

>Sincerely,

>Gene Wirchenko

>Computerese Irregular Verb Conjugation:
>     I have preferences.
>     You have biases.
>     He/She has prejudices.



Sun, 17 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

Quote:

>Um...

>A "collective noun" is a singular word form used to represent a multiple

                          ^^^^^^^^^^^^^^^^^^
     I didn't know that.  You're sure?

Quote:
>entity.  There is some dialectical variation in verb usage (in Australian
>english, one says "the company are announcing record profits", which always
>sounds odd to my American ear, for example), but to the best of my knowledge

  1) Do you have another kind of ear?  European, perhaps?

  2) And to my Canadian ears.  Note the plural on "ears" <G>.

Quote:
>(and the reference books I have to hand), plural noun forms are never
>collective.  It may very well be, as you say, common usage.  That does not
>make it correct.

     True enough.

Quote:
>In any event, if Tony _were_ to use "Data", he would have to use "Labels"
>for the sake of consistency.

     Maybe.  Consistency is a hobgoblin of something or other.  Isn't
it appropriate that I'm mangling that quote?

     I've had this struggle on table naming, that is, is it a client
table or a clients table.  I've gone (generally) with the singular.

Quote:
>I suppose the form used for attribute names is a somewhat arbitrary
>decision.  I use the singular form, since I have found it less confusing for
>the users.  No one is confused by a list of names with the heading
>"Surname".  Most people, I think, would be confused by a text field with the
>caption "Surnames".  (Think of swapping back and forth between datasheet and
>form view in Access.)

     Maybe.  If you asked for a list of all the different surnames in
a table, "surnames" would be more natural than "surname" (IMNSHO).
          select distinct surname from ...
                                 ^
Wouldn't an "s" make more sense here?
          surname
                 ^
And here?
          Aardvark
          Abbey
          Ackerman
          ...

Quote:
>When I grow up and they make me god, I might require that everybody use the

     Forget it.  You're too humble, so We aren't going to do it.

Quote:
>singular form for attribute names, but until then, you are of course free to
>use whatever form you like with nary a peep from me.  I will complain,
>however, if you're not consistent.

     You'll be going after those who flip between pronouncing "data"
as "day-tuh" and "dah-tah", too.  I normally use "day-tuh", but for
emphasis will use "dah-tuh" SOMETIMES.

[snipped previous]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.



Sun, 17 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?


Quote:

>>Um...

>>A "collective noun" is a singular word form used to represent a multiple
>                          ^^^^^^^^^^^^^^^^^^
>     I didn't know that.  You're sure?

Yep.  I've embarassed myself in public so many times that I always check
before I mouth off like this.  (Not that it's stopped me embarassing myself
in public, mind you, but that's another story...)

Webster's Collegiate:  "...designating a noun which is singular in form but
denotes a collection of individuals"

Quote:

>>entity.  There is some dialectical variation in verb usage (in Australian
>>english, one says "the company are announcing record profits", which
always
>>sounds odd to my American ear, for example), but to the best of my
knowledge

>  1) Do you have another kind of ear?  European, perhaps?

Yep, that too.  And perfect pitch, if anyone should ask.

Quote:

>  2) And to my Canadian ears.  Note the plural on "ears" <G>.

One has "an ear for..." things, doesn't one?

Quote:

>>(and the reference books I have to hand), plural noun forms are never
>>collective.  It may very well be, as you say, common usage.  That does not
>>make it correct.

>     True enough.

>>In any event, if Tony _were_ to use "Data", he would have to use "Labels"
>>for the sake of consistency.

>     Maybe.  Consistency is a hobgoblin of something or other.  Isn't
>it appropriate that I'm mangling that quote?

Hmm...I just love the opportunity to be pedantic <g>.  What Emerson
_actually_ said was "A _foolish_ consistency is the hobgoblin of little
minds, adored by little statesmen and philosophers and divines."  (emphasis
added)

Quote:

>     I've had this struggle on table naming, that is, is it a client
>table or a clients table.  I've gone (generally) with the singular.

LOL.  For tables, I use the plural, it's _fields_ I think should be
singular.

Quote:

>>I suppose the form used for attribute names is a somewhat arbitrary
>>decision.  I use the singular form, since I have found it less confusing
for
>>the users.  No one is confused by a list of names with the heading
>>"Surname".  Most people, I think, would be confused by a text field with
the
>>caption "Surnames".  (Think of swapping back and forth between datasheet
and
>>form view in Access.)

>     Maybe.  If you asked for a list of all the different surnames in
>a table, "surnames" would be more natural than "surname" (IMNSHO).
>          select distinct surname from ...

                                 ^

Quote:
>Wouldn't an "s" make more sense here?
>          surname
>                 ^
>And here?
>          Aardvark
>          Abbey
>          Ackerman
>          ...

Yes, if you are dealing with a list, absolutely a plural label makes more
sense.  My point was that a label that may be used for both lists and single
values, a singular form is less likely to confuse.  (Unlike that last
sentence, for which my apologies <g>).

Quote:
>>When I grow up and they make me god, I might require that everybody use
the

>     Forget it.  You're too humble, so We aren't going to do it.

Me?  Humble?  You're confusing me with Dev.  (I'm flattered!)

Quote:
>>singular form for attribute names, but until then, you are of course free
to
>>use whatever form you like with nary a peep from me.  I will complain,
>>however, if you're not consistent.

>     You'll be going after those who flip between pronouncing "data"
>as "day-tuh" and "dah-tah", too.  I normally use "day-tuh", but for
>emphasis will use "dah-tuh" SOMETIMES.

Ooo, I refuse to discuss accents.  Mine's hopeless.  I sound like a
foreigner to _everybody_.

    - Rebecca.



Sun, 17 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

Quote:




>>>Um...

>>>A "collective noun" is a singular word form used to represent a multiple
>>                          ^^^^^^^^^^^^^^^^^^
>>     I didn't know that.  You're sure?

>Yep.  I've embarassed myself in public so many times that I always check
>before I mouth off like this.  (Not that it's stopped me embarassing myself
>in public, mind you, but that's another story...)

>Webster's Collegiate:  "...designating a noun which is singular in form but
>denotes a collection of individuals"

     Thank you.

[snip]

Quote:
>>  2) And to my Canadian ears.  Note the plural on "ears" <G>.

>One has "an ear for..." things, doesn't one?

     But that is an idiom.  Your use wasn't.

     Then there's the you/one bit.

[snip]

- Show quoted text -

Quote:
>>     Maybe.  Consistency is a hobgoblin of something or other.  Isn't
>>it appropriate that I'm mangling that quote?

>Hmm...I just love the opportunity to be pedantic <g>.  What Emerson
>_actually_ said was "A _foolish_ consistency is the hobgoblin of little
>minds, adored by little statesmen and philosophers and divines."  (emphasis
>added)

>>     I've had this struggle on table naming, that is, is it a client
>>table or a clients table.  I've gone (generally) with the singular.

>LOL.  For tables, I use the plural, it's _fields_ I think should be
>singular.

     Huh?  Why?  I don't follow.

[snip]

- Show quoted text -

Quote:
>>     Maybe.  If you asked for a list of all the different surnames in
>>a table, "surnames" would be more natural than "surname" (IMNSHO).
>>          select distinct surname from ...
>                                 ^
>>Wouldn't an "s" make more sense here?
>>          surname
>>                 ^
>>And here?
>>          Aardvark
>>          Abbey
>>          Ackerman
>>          ...

>Yes, if you are dealing with a list, absolutely a plural label makes more
>sense.  My point was that a label that may be used for both lists and single
>values, a singular form is less likely to confuse.  (Unlike that last
>sentence, for which my apologies <g>).

     You need to apologi[zs]e more than once?  Let's take up Chinese.
AFAIK, it doesn't have plurals.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.



Sun, 17 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
The chat police are going to be on us any minute now, but I'm enjoying
this.....


Quote:

>>>  2) And to my Canadian ears.  Note the plural on "ears" <G>.

>>One has "an ear for..." things, doesn't one?

>     But that is an idiom.  Your use wasn't.

Well, yes, it was, actually.  _That_ idiom.  I have (or like to think I
have) an ear for language.  And _American_ ear for language.

Quote:

>     Then there's the you/one bit.

Which you/one bit?

Quote:

>>>     I've had this struggle on table naming, that is, is it a client
>>>table or a clients table.  I've gone (generally) with the singular.

>>LOL.  For tables, I use the plural, it's _fields_ I think should be
>>singular.

>     Huh?  Why?  I don't follow.

Tables are collections, so I use the plural form.  For fields, I use the
singular.  Thus the "Employees" table has a "Gender" field.  It's just what
makes sense to me.

Quote:
>>Yes, if you are dealing with a list, absolutely a plural label makes more
>>sense.  My point was that a label that may be used for both lists and
single
>>values, a singular form is less likely to confuse.  (Unlike that last
>>sentence, for which my apologies <g>).

>     You need to apologi[zs]e more than once?  Let's take up Chinese.
>AFAIK, it doesn't have plurals.

Aw, that would take all the fun out of it <g>.

    - Rebecca.



Mon, 18 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

Quote:

>>     Then there's the you/one bit.

>Which you/one bit?

     Well, you can use "one" or one can use "you".

Quote:
>>>>     I've had this struggle on table naming, that is, is it a client
>>>>table or a clients table.  I've gone (generally) with the singular.

>>>LOL.  For tables, I use the plural, it's _fields_ I think should be
>>>singular.

>>     Huh?  Why?  I don't follow.

>Tables are collections, so I use the plural form.  For fields, I use the
>singular.  Thus the "Employees" table has a "Gender" field.  It's just what
>makes sense to me.

     A table is a level of abstraction.  At the table level, it is a
singular entity.  When dealing at the field level, for each table,
there is (almost always) a plurality.  For a parallel, think of a bag
then think of the potato chips inside it.

     The Employee table contains name and gender fields.

     It's just what makes sense to me.  <gd&r>

     Fields are collections of bytes/bits.  <GD&R>

Quote:
>>>Yes, if you are dealing with a list, absolutely a plural label makes more
>>>sense.  My point was that a label that may be used for both lists and
>single
>>>values, a singular form is less likely to confuse.  (Unlike that last
>>>sentence, for which my apologies <g>).

>>     You need to apologi[zs]e more than once?  Let's take up Chinese.
>>AFAIK, it doesn't have plurals.

>Aw, that would take all the fun out of it <g>.

     No, it has its own fun.  In Cantonese, noun have a classifier
when dealing with numbers (singular or plural) of them.  (<FX: gasp!>
Practically our problem.)
          yat ma ma         incorrect: one mama
          yat goh ma ma     correct: one body mama
"goh" is (often, usually) used with bodies.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.



Mon, 18 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Cor!
-----
<g>
Arvin Meyer

Quote:

>Ear Ear.... Wots all this Then ?
>Chat on the Newsgroup..... ?
>That'll be enough of that then.
>Lets be aving ya !
>Move along ladies and gentlemen......
>Move along.....

>--------
>Henry Craven
>-----------------------

>-----------------------------------------------------------
>Theme for the Year
>Off with the 90s and on with the Noughties..
>-----------------------------------------------------------



Mon, 18 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Ear Ear.... Wots all this Then ?
Chat on the Newsgroup..... ?
That'll be enough of that then.
Lets be aving ya !
Move along ladies and gentlemen......
Move along.....

--------
Henry Craven
-----------------------

-----------------------------------------------------------
Theme for the Year
Off with the 90s and on with the Noughties..
-----------------------------------------------------------


Quote:
>The chat police are going to be on us any minute now, but I'm enjoying
>this.....



>>>>  2) And to my Canadian ears.  Note the plural on "ears" <G>.

>>>One has "an ear for..." things, doesn't one?

>>     But that is an idiom.  Your use wasn't.

>Well, yes, it was, actually.  _That_ idiom.  I have (or like to think I
>have) an ear for language.  And _American_ ear for language.

>>     Then there's the you/one bit.

>Which you/one bit?

>>>>     I've had this struggle on table naming, that is, is it a client
>>>>table or a clients table.  I've gone (generally) with the singular.

>>>LOL.  For tables, I use the plural, it's _fields_ I think should be
>>>singular.

>>     Huh?  Why?  I don't follow.

>Tables are collections, so I use the plural form.  For fields, I use the
>singular.  Thus the "Employees" table has a "Gender" field.  It's just what
>makes sense to me.

>>>Yes, if you are dealing with a list, absolutely a plural label makes more
>>>sense.  My point was that a label that may be used for both lists and
>single
>>>values, a singular form is less likely to confuse.  (Unlike that last
>>>sentence, for which my apologies <g>).

>>     You need to apologi[zs]e more than once?  Let's take up Chinese.
>>AFAIK, it doesn't have plurals.

>Aw, that would take all the fun out of it <g>.

>    - Rebecca.



Tue, 19 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?
Lot's of snips....


Quote:

>>>     Then there's the you/one bit.

>>Which you/one bit?

>     Well, you can use "one" or one can use "you".

<giggle>

Quote:
>     A table is a level of abstraction.  At the table level, it is a
>singular entity.  When dealing at the field level, for each table,
>there is (almost always) a plurality.  For a parallel, think of a bag
>then think of the potato chips inside it.

Okay, good analogy...it's a "bag" (sing.), I grant you.  Actually, as long
as we're being pedantic, "bag" is more correct than "collection", since a
relation is inherently unordered.

However, if I want you to fetch me something out of the pantry, I'll ask for
the "potato chips" (plural) as opposed to, say the "shitake mushrooms",
(which don't go nearly so well with a Coke).  In naming tables, we're
talking about "which bag", not "a bag", aren't we?

Quote:
>     The Employee table contains name and gender fields.

>     It's just what makes sense to me.  <gd&r>

>     Fields are collections of bytes/bits.  <GD&R>

I'm sure I'd be giggling if I knew what <gd&r> stood for.

Yes, fields _are_ physically collections of bits, but that's not the logical
level at which we're working when doing db design.  By definition, fields
are supposed to be atomic.  Which I interpret to mean that any decomposition
below the field is irrelevant to the problem space.  So I think your point
is moot, isn't it?  (I'm prepared to be wrong here).

Quote:

>>>>Yes, if you are dealing with a list, absolutely a plural label makes
more
>>>>sense.  My point was that a label that may be used for both lists and
>>single
>>>>values, a singular form is less likely to confuse.  (Unlike that last
>>>>sentence, for which my apologies <g>).

>>>     You need to apologi[zs]e more than once?  Let's take up Chinese.
>>>AFAIK, it doesn't have plurals.

>>Aw, that would take all the fun out of it <g>.

>     No, it has its own fun.  In Cantonese, noun have a classifier
>when dealing with numbers (singular or plural) of them.  (<FX: gasp!>
>Practically our problem.)
>          yat ma ma         incorrect: one mama
>          yat goh ma ma     correct: one body mama
>"goh" is (often, usually) used with bodies.

Oh, heavens, I have a dirty mind....

    - Rebecca.



Tue, 19 Jun 2001 03:00:00 GMT
 Good user friendly custom fields terminology?

[snip]

Quote:
>>     A table is a level of abstraction.  At the table level, it is a
>>singular entity.  When dealing at the field level, for each table,
>>there is (almost always) a plurality.  For a parallel, think of a bag
>>then think of the potato chips inside it.
>Okay, good analogy...it's a "bag" (sing.), I grant you.  Actually, as long
>as we're being pedantic, "bag" is more correct than "collection", since a
>relation is inherently unordered.

     Both refer to sets.  Both can be unordered.

Quote:
>However, if I want you to fetch me something out of the pantry, I'll ask for
>the "potato chips" (plural) as opposed to, say the "shitake mushrooms",
>(which don't go nearly so well with a Coke).  In naming tables, we're
>talking about "which bag", not "a bag", aren't we?

     I wondered briefly on this.  I think it's like that because there
isn't a *usually* used special name for the container level of
abstraction.  "snack" comes close, but is indeterminate as it could be
referring to a small snack (one potato chip) or a big snack (the whole
bag).

     A table consists of fields.  Note the difference in words.  It's
"table" not "collection of fields" or similar.

Quote:
>>     The Employee table contains name and gender fields.

>>     It's just what makes sense to me.  <gd&r>

>>     Fields are collections of bytes/bits.  <GD&R>

>I'm sure I'd be giggling if I knew what <gd&r> stood for.

     "grin, duck, and run": used when making a somewhat facetious or
humorous point.

Quote:
>Yes, fields _are_ physically collections of bits, but that's not the logical
>level at which we're working when doing db design.  By definition, fields
>are supposed to be atomic.  Which I interpret to mean that any decomposition
>below the field is irrelevant to the problem space.  So I think your point
>is moot, isn't it?  (I'm prepared to be wrong here).

     My point is that it is the abstraction level.

     Fields can and should be decomposed.  How else would you validate
many data types?

     A postal code in Canada consists of seven chanracters:
          1     capital alphabetic type 1
          2     digit
          3     capital alphabetic type 2
          4     space
          5     digit
          6     capital alphabetic type 2
          7     digit
where type 2 excludes D, F, I, O, Q, and U and type 1 excludes type
2's exclusions plus W and Y.  You have to decompose the field to
validate it as having the correct format.

     The first character determines the province.  The first three
determine the delivering post office.  An mailing list app could be
very concerned with field parts.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.



Tue, 19 Jun 2001 03:00:00 GMT
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. User-Friendly Field Names

2. User Friendly Ways To Make Multiple Selections From One Field

3. VB6, ADO Datacontrol, and multiple concurrent users: making a friendly user interface

4. VB6, ADO Datacontrol, and multiple concurrent users: making a friendly user interface

5. Finding an Oracle User Terminology List

6. terminology - instance, user, tablespace

7. YOUR OPINION: The best FileMaker-Friendly HTML Editor

8. Terminology confusion : Column or Field

9. updating SQL (add delete) w/ user-friendly tool

10. user-friendly manipulation of SQL records

11. user-friendly search strings

12. S: user-friendly sql query builder


 
Powered by phpBB® Forum Software