The problem is that each well can have a different number of and types of
layers. Trying to pre-plan all the combinations could be a big headache. My
first thought is the following layout-
well_number layer_number bottom_depth layer_type
1 1 10 topsoil
1 2 25 gravel
and so on. The bottom_depth of one layer is the top_depth of the one below.
The final bottom_depth is the depth of the well.
The layer_types can be pulled from another table to maintain consistency and
allow for new types as needed. Come report time you order by
well_no,layer_number to get the desired information.
On Monday 21 November 2005 05:29 pm, Dennis Veatch wrote:
> On Monday 21 November 2005 20:04, Michael Glaesemann wrote:
> > On Nov 22, 2005, at 3:19 , Dennis Veatch wrote:
> > > I had thought just adding some fields called topsoil_start/
> > > topsoil_end,
> > > gravel_start/gravel_end, etc. But them I'm left with how to take
> > > those values
> > > and give to total depth for each layer and total depth of the well.
> > >
> > > But I'm not sure that is the best way to handle this.
> > >
> > > Does anyone have some other suggestions?
> >
> > This is similar in concept to temporal intervals. You might want to
> > look at "Temporal Data and the Relational Model" by Date, Darwen, and
> > Lorentzos for general theory, and "Developing Time-Oriented Database
> > Applications" by Richard Snodgrass for implementations in SQL. The
> > latter is available as a PDF download (the book itself is out of print):
> > http://www.cs.arizona.edu/people/rts/tdbbook.pdf
> >
> > Hope this helps!
>
> Hee, well that's um, kinda over my head. Hee and I'm not all the way
> through the PostgreSQL book I just bought. There's probably a gap there. :)
>
> Though I will try to glean something out of the link.
--
Adrian Klaver
aklaver@comcast.net
