Here are just a few observations.
What you have described is a classic taxonomy problem. The simplest approach
is to create a table to contain the basic attributes of the obtjects in the
database. Using your example, such attributes may be anatomical (two eyes, two
ears, four limbs, one backbone, c.), ecological (categories of food items,
such as plant, animal, fungal, c., temperature tolerances, c.), conventional
taxonomic data (such as genus, family, class, phylum, c.). You might even get
creative and choose to use additional novel or unconventional kinds of
attributes. And you could go so far as to add a dynamic classification scheme
based on conventional or novel numeric taxonomic algorithms, so the data itself
provides a natural classification hierarchy. Additional tables may provide
more useful predictive capability, such as a table representing empiric
observations (based either on field observation or analysis of gut contents) of
what eats what (e.g. on date x animal y was observed
eating z by Fred at location Q). Analysis of such a table could provide bases
for inferences such as animal x eats mammals of the family or animal y eats
only insects, and all insects that will fit in its mouth. This avoids a need
for predefined relationships, and a suite of probable relationships can be
constructed directly from the basic data. It also provides support for a
measure of predictive capability. For example, if animal x has been observed
eating mule deer, you might predict that it may also eat white tail deer where
they coexist even if the animal has not been observed eating white tail deer.
I'd suggest avoiding the route involving defining very high dimensional
spaces. That gets unweldy very quickly, and you'll find that most of such high
dimensional spaces is empty.
The probability of observing grass eating a cow is identically 0. But the
probability of observing pitcher plants, sun dews, or venus fly traps eating
insects is identically 1, on the condition you make an effort to study
carnivorous plants. :-) The number of possible relationships between objects
increases as n! where n is the number of objects, but the number of kinds of
relationships will be small.
No one can tell you what the right approach is or what a better way to do
what you want to do might be, at least from what you have said so far. You
haven't said precisely what you want to accomplish. Is it simple information
management, to tell your users what they already know? Or perhaps it is a
research tool. Or maybe it is simple record keeping, and may rarely if ever be
used except for audit purposes.
The only way to provide the kind of answers you want, regarding a comparison
of options for managing and using your data, is to do a formal analysis of your
problem and how your users may want to use your product. You might want to
begin with a problem definition, from the perspective of a client or end user,
and then work up a few use case scenarios. And then, from that, you can work
up a prototype data model with an entity-relationship diagram (NB: these
relationships may or may not be related to the relationships you want to
capture from your data - there are different kinds of relationships just as
there are different kinds of models - don't you just love the fact natural
language is multivocal?). Until this homework is done, the best you'll likely
get are a few general observations of the sort I have offered (and I do so from
the perspective of an ecologist who happens to develop software). You will
want to ensure that any example you offer to illustrate what you
want to do is directly related to the actual problem you are trying to solve.
Otherwise the advice you get may be inappropriate. The data model I'd use for
a decision support tool for government officials responsible for environmental
protection (such as at the EPA in the US) will be quite different from what I'd
use for a university researcher, and both will be different from what I'd use
for a financial consultant or a human resources office. What you need to do
will be as dependant on what real world problem you're trying to solve as it is
on what data is available. A tool to support research in the life sciences
will probably not want to store relationships among living things explicitly,
preferring to infer them from data analysis, but a tool for a government
environmental regulator will instead likely want to store them explicitly (e.g.
as input to simulation models used to assess dose and risk issues).
Why wait for quantum computers? Don't sell the computers available today
short. You can run mesoscale weather models on a modern desktop (the ones that
used to run on mainframes only a few years ago, not the highly detailed ones
used on mainframes now). I have done ecosystem scale modeling using desktop
machines, even those available ten years ago.
