NYCPHP Meetup

[Jeff]

Doesn't really change my thinking...however...the question is how
normalized should the data be (or even need to be). For example, a
lookup table as described below (tlkpStability) adds a fair amount of
flexibility but, depending on how far you go with normalizing data, it
can also make queries a bit more complex. 

The real questions concerning the approach to take come down to:

	a. Is this an application you've got to knock out real fast and
which will never be used again except in this particular instance? If
yes, you can go with a "fast and dirty" approach. However, applications
sometimes take on a life of their own and this "quicky" application may
blossom into something you have to maintain regularly...if that happens
you'll regret the "fast and dirty" approach.

	b. If there will be any reporting based on the data (I assume
there will be), will a single table allow you to partition the data as
needed? The answer may be yes.

Jeff


-----Original Message-----
From: Joshua S. Freeman [mailto:jfreeman at amnh.org] 
Sent: Wednesday, May 14, 2003 3:34 PM
To: NYPHP Talk
Subject: Re: [nycphp-talk] form confusion...


Hi Jeff,

this area of 'structural stability' is one of several areas in the
survey form.

with this, and some other parts of the survey, you can select 1 of four
or five options (radio buttons) as a value but also, for any given
row/specimen there may also be one or two additional bits of information
that should be part of the value for that specimen (these are the
checkboxes...)

does this change your thinking at all?

J.

On 5/14/03 4:05 PM, "Jeff" <jsiegel1 at optonline.net> wrote:

> I got into the conversation a bit late and tried to read through the 
> thread so here's my basic understanding of the situation.
> 
> You've got a ton of specimens. Specimens are "classified" by 
> structural stability, etc. so that each of these "attributes" are 
> specific to a specimen. I would handle it as follows:
> 
> tblSpecimen (specimen table - the "parent" table)
> SP_ID - autoincrement ID number
> frkST_ID - int field - foreign key to tlkpStability SP_sSpecimenName 
> varchar field (Add'l fields as needed)
> 
> Things like stability, etc., should go in lookup tables...for example,
> 
> tlkpStability (each row has its own ID number and a description) ST_ID

> autoincrement ST_sStability
> 
> Instead of radio buttons you use a dropdown. That way, if they have 
> four choices of structural stability at this point in time but...after

> examining 100 specimens they realize they need a fifth choice, it can 
> be added to the table and it would automatically appear in the 
> dropdown. You wouldn't have to reprogram your form by adding an 
> additional radio button.
> 
> If you have only two possible choices for a particular specimen, that 
> could go into tblSpecimen. I use lookup tables when there are 3 
> choices or more (not that they couldn't also be in tblSpecimen... 
> however...if the choices could change over time...using a separate 
> lookup table makes life easier).
> 
> Jeff
> 
> -----Original Message-----
> From: Joshua S. Freeman [mailto:jfreeman at amnh.org]
> Sent: Wednesday, May 14, 2003 2:35 PM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] form confusion...
> 
> 
> Thanks for the response Jeff..
> 
> On 5/14/03 3:21 PM, "Jeff" <jsiegel1 at optonline.net> wrote:
> 
>> It would seem that if the structural stability choices are mutually 
>> exclusive, then they would go into a single database column. The same

>> would apply to the checkboxes.
> 
> in the same table though?
> 
> 
> 
>> 
>> Jeff
>> 
>> -----Original Message-----
>> From: Joshua S. Freeman [mailto:jfreeman at amnh.org]
>> Sent: Wednesday, May 14, 2003 2:13 PM
>> To: NYPHP Talk
>> Subject: [nycphp-talk] form confusion...
>> 
>> 
>> First off, thanks to the many people who helped me out with my 
>> previous question about making it possible for people to upload 
>> images.  I'm not there quite yet but when I get there I'm sure the 
>> answers I received will be incredibly helpful.  Thanks again.
>> 
>> I'm working on the same project.. in brief, a scientist has about 
>> 1000 specimens of the same kind of thing and wants to make a database

>> containing a survey of these 1000 specimens.  The main table in the 
>> database is the 'specimen'table, but that table has lots of fields 
>> for
> 
>> the 'id' number of records in related tables.
>> 
>> In most cases, it's clear from the form whether or not I need to 
>> build a table to relate to the main 'specimen' table but in some 
>> cases, it's
> 
>> not so clear.
>> 
>> Here's an example of what I mean:
>> 
>> in the form, there's an area called 'structural stability'.  Someone 
>> filling out the form can select for a few radio button:
>> 
>> -----------snip-----------------
>> 
>> <input type="radio" name="structural stability" value="stable">stable
>> 
>> <input type="radio" name="structural stability" value="slightly 
>> unstable">slightly unstable
>> 
>> etc...
>> 
>> ---------------snip-------------
>> 
>> in addition to 4 possible radio buttons, there are also 2 checkboxes 
>> associated with the idea of 'structural stability':
>> 
>> ---------------snip-------------
>> 
>> <input type="checkbox" name="structural stability" value="inadequate 
>> storage support"> inadequate storage support
>> 
>> <input type="checkbox" name="structural stability" value="current
> insect
>> activity">   current insect activity
>> 
>> ---------------snip-------------
>> 
>> so, here's my question:
>> 
>> right now, i have the name of all the radio buttons and the 
>> checkboxes as 'structural stability'
>> 
>> i'm not sure, however, how to handle this on the database side of 
>> things. Should I give the checkboxes different names and their own 
>> tables?
>> 
>> I'm a little confused at the moment and would love someone with more 
>> experience to shine some light on the path...
>> 
>> Thanks in advance..
>> 
>> And rest assured that once I'm done with this project I should be in 
>> shape to begin offering up some advice of my own to new newbies.
>> 
>> Thanks!
>> 
>> Joshua
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



--- Unsubscribe at http://nyphp.org/list/ ---