All About the Custom Databases

As you probably already know, we have nearly 200 custom databases, each dedicated to a specific kind of plant. Daylilies, Irises, Roses, Sempervivum Hostas, etc. Each of these databases is comprised of most or all of the cultivars and species of their particular plant types.

Back when we first created All Things Plants, we didn't have a database of plants. What we had was a sister website, Cubits.org, which at the time had a good number of communities dedicated to the various plant types. There was a Daylilies cubit, and a Roses cubit, and so on. These cubits had their own individual databases that they controlled, and those databases had special data fields that applied directly to their kind of plant.

So, when we decided to build a database of plants here at ATP, I approached those cubit owners and asked whether they would be interested in closing their cubits and moving their plant info over to ATP, and nearly all of them agreed to do so. So the challenge for me at that point was to design a system that would handle this huge variety of plant information.

Roses had their specific classifications. Daylilies had their own terms (ploidy, etc) and on and on. The only solution was to design the ATP Plant Database to be patterned after the Cubits approach. A central database would exist, yes, and every plant in the database is a member of that central database, but it would also be sectioned off into different plant types.

The main database was built with a central architecture. Data common to all plants, such as life cycle (Annual, Perennial, etc), sun requirements, water requirements, propagation methods, and so forth, applied to all plants through what we called the "Primary Plant Details." Once that was done, I then created the Parent Plant feature. I could then create a top-level plant, like Daylilies (Hemerocallis), and this would then be marked as a Parent Plant. Then all cultivars that match the genus of that parent become "child plants," and in this way I now have a collection of similar plants, all under the umbrella of this parent plant.

Next step: Create a custom data architecture for each parent plant we made. For daylilies we went through and added options for the hybridizer, the ploidy, foliage type, scape height, bud count, bloom traits particular to daylilies, and so forth. With that done, people could then add new daylilies and the system would automatically associate those new plants with that parent plant, and then all the special new data fields are now available.

From there it was easy to start adding new features, and I called the entire collection of parent plants "Custom Databases." I made a way to give special moderator powers to these various custom databases, so that I could make @Calif_Sue be over daylilies, and @zuzu over roses. @valleylynn and @goldfinch4 took over sempervivum, and so forth. Many custom databases remained without a moderator, and the day-to-day work on them fell to me and, not much later, to the Plants Admins.

The Parent Plant is the rule-maker for its database. As mentioned above, whatever its genus happens to be determines the plants that will fall under its purview. The parent plant for daylilies has as its genus 'Hemerocallis,' and therefore all plants with the genus 'Hemerocallis' are under that database. Now, the parent plant also has a common name field, and any new plant added to that database "inherits" the same common name. So all plants in the Hemerocallis genus automatically get 'Daylily' added as their common name. Nice, eh? Well, it gets better!

Looking at the Beans (Phaseolus vulgaris) parent plant, notice that it has General Plant Information already checked off. Since this is a parent plant, we're indicating here that these details are common to ALL matching plants. So we are saying that all beans are annual herbs, needing full sun, used as vegetables, providing edible fruit, nitrogen fixing, attracting bees, etc. Now whenever a new bean is created, these data fields propagate down to the new plant. This way we can quickly copy our data down to all matching plants! If we want to add a new field to all beans, we simply edit the data for the parent plant and that data is automatically copied down.

Another feature of the custom databases is that we can provide an internal link between that database and any forum on the site. So since we have a forum for daylilies, we can link the daylilies database to it, and then we get lots of new features. Look at the forum's front page, and you'll see over on the right that we can show recent images and comments from the daylilies database. Conversely, if you're looking at the front page of the daylilies database, you will see at the top a list of the most recent threads in the daylilies forum. Pretty snazzy.

Another feature that came up pretty quickly was the Search by type, aka the Advanced Search. You can go into a custom database and then click on "Search by characteristics," or click on "Search by type" in the blue bar on the left. From there you can perform the most powerful plant search available online. Check off all the required fields and the engine will return the plants that match just those items you checked off. Using this tool, you can see that there are 7 daylilies that are diploid, evergreen, reblooming with double blooms and have won the Award of Merit. Isn't that just wonderful?!

Although this was a lot of information, it is really just an intro to this powerful aspect of ATP. There is so much more to it than I can write; in fact I believe a short book could be written on the topic of this. The custom database is one of our not-so-secret weapons that makes the ATP database the powerful tool that it is.