Re: Index Keys for Hybridization Database
>>"We are never too old to act immature."
True....A finance professor of mine once said, "If you never grow up, you'll
never grow old". I liked the import of that statement and have conducted my
Let's try a different approach to communication. I'll ask a question, a
serious one, and I'll see what kind of response I get. Maybe some of these
immature rascals can help me out because when it comes to Hostas, I'm still
really quite young in my pursuit of knowledge. If I don't get any serious
takers, then I'm going to go back to trying to keep Chic from picking on
Database Design to track Hybridization efforts :
Objective - System that is flexible, supportable for the balance of my life
(from 1 day to 51 years, give or take a few years), infinitely
comprehensive, intuitively relevant (i.e. the assigned numbering schema
could be explained to some other human being on the planet and they would
say, "Oh, I see what you're doing"), and yet simple enough that the initial
user--i.e. the Emerging Hostaholic now turned Maturing Plantsman--can put
the schema to good use immediately.
1) I go to this site, http://www.rbge.org.uk/BG-BASE/welcome.htm#top , look
under modules at this location, http://www.rbge.org.uk/BG-BASE/modules.htm ,
and then choose Living Collections. I click on the diagram which is
displayed if you click here, http://www.rbge.org.uk/BG-BASE/diaglc.gif and
see a rather elegant design of a database that keeps track of just about
everything I'd ever want to know about a plant. I'd like to purchase this
module (I've sent them a message and told them so--there is no pricing info
at the site--yet have not received a reply), as well as the underlying
database engine "Revelation", but I'm not convinced that I am not able to
design something that is a subset of this database design that won't be
sufficiently comprehensive for my needs, yet require no additional
investment (a quadruple negative). This is worth exploring because I have
a feeling the module and Revelation price tag could be more than my monthly
2) If I were Paul Aden, Eric Smith, Alex Summers, or any of a host of
adequately intelligent human beings who are already hybridizing and not
getting their planned crosses confused, I wouldn't need to ask for input. I
would just make the decision and use the schema whether it was optimized, or
not. Or, maybe it's not a matter of intelligence, but one of maturity, I'm
not certain. I'm only 49 and these guys are about, well they're a couple
years older than I.
3) I can't invest inordinate amounts of design work, programming, etc.
because this is a not-for-profit portion of the enterprise--i.e. it's more
for the fun of it than for any anticipated commercial benefit. But even
worse, I'd hate to invest whatever time I do and then have to scrap the
entire mess several years hence because of some oversight that could have
Okay, now that we have the assumptions, let's talk database design and the
primary problems, as I see them.
I need to track the pod and pollen parent. The tag that I am using is a
Jeweler's tag, made of Tyvek and destined to be wrapped around the pedicel,
just beyond the ovary but above the bract so that it won't slide down the
scape. The index key must show
1) Pod Parent (PP)
2) Pollen Parent (pp)
3) Year Crossed (XX)
and possibly an additional field would be inscribed on the tag, one of some
value, the date the cross was performed. This affords one the possibility
of tracking how soon the pod is mature.
That's the problem and it just that simple.
I have about 20 "momma breeders" targeted to serve as the mares in this
little harem for next year (I expect this number to increase, I don't know
exactly why, but I have to plan for it). I could assign a two-digit chunk to
the key for the Pod Parent (PP), and a two-digit chunk for the pollen parent
(pp). The year will be a two-digit chunk (I'm at a loss right now to find
the word that means parcel of data--thus I have coined "chunk").
Since I'm shooting for clarity here and a serious answer, let's say I choose
H. William Lachman as an example and next year, my main plant offers up at
least one Inflorescenses--Flowers. My goal will be to scamper out to the
garden in the morning and cut the tepals back, exposing the stigma and
anthers, cut off the anthers (ouch!), cause a little quick romance to occur
between mommy and daddy, and then to label this cross. I want to do this
often enough that I make sufficient crosses during the season to have
adequate work to do to keep me out of trouble. I believe this will be about
500 crosses, give or take a few hundred.
Here is my dilemma:
Let's say I call William Lachman "WL", and I call H. 'Ventricosa', VC, and
the year is 2001--The key to the resultant seedling, which needs to be
forevermore identified in the database, is WLVC01. Now, two years later, I
have a seedling from this cross that is mature enough to bloom and I want to
use it as a PP. I assume that I will have to give any resultant seedlings
their own index key. That wouldn't be too bad, actually, because it would be
easy to remember and I could conceivably have an index key that would
support 14 characters--6 for our hybrid PP, 6 for some other F1 hybrid pp,
and still 2 characters for the year. So I make another cross and the
seedling becomes .... WL0V01SPTL0103..... William Lachman crossed with
Ventricosa, performed in 2001, and Sea Prize crossed with Torchlight
performed in 2001, and the union of the two was performed in 2003.
Two years later (wishful thinking), in 2005, I want to use this seedling as
a PP. And I use another seedling with a similarly long name as the pp.
Well, I've run out of space on my tag. 28 characters just won't fit. So,
now 5 years later I have to scrap the whole schema and switch to a number,
or an Alpha numeric, index key.
So, that's my question. How do I assign a numbering schema that makes
intuitive sense and still fit it on the tag. I believe I cannot, so I
imagine I will have to have a database with all of the crosses listed and
numbered and if I ever lose that database, there will be no way to know
what's what. I do believe I can come up with some index from which one can
draw some information from the key, ie. the year may be the leading
character, starting with 2001 as an A, etc., etc. HOWEVER, I want to cheat
and find out what people, who are using a sophisticated system like BG-BASE,
are doing to build such a database.
So there you have it. A mature question, and serious one.
Thanks for anyone's help!
The Maturing Plantsman
To sign-off this list, send email to firstname.lastname@example.org with the
message text UNSUBSCRIBE HOSTA-OPEN