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@xxxxxxxxxxx
