Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)
Date: 10 Jun 2004 09:55:11 -0700
Message-ID: <4b45d3ad.0406100855.1737469_at_posting.google.com>
> A fraud and a liar, with a half-baked product that makes even MS
> Access look good.
Please show Neo is a "fraud and a liar" by posting the report for the following data which is one of "any hierarchy", using either RM Sol#1 or #2 "from normalized and NULL-less data" (or a solution as generic and normalized using another RM based db such as MS Access):
God is the parent of an unnamed person. God is also the parent of second person with three names (string 'john', integer 100, decimal 3.14).
The first person represents a thing that doesn't have a particular attribute and the second person represents a thing that has an attribute with three values, each of different type. Below is the equivalent XDb1 script:
string isa thing.
integer isa thing.
decimal isa thing.
john isa name.
john isa string.
100 isa name.
100 isa integer.
3.14 isa name.
3.14 isa decimal.
god isa thing.
person isa thing.
* isa person. (an unnamed person) * parent god. * isa person. (another unnamed person) *'s name is john. (assign first name) *'s name is 100. (assign second name)*'s name is 3.14. (assign third name) *'s parent god.
Below is XDb1's report for the above hierarchy:
Common 'parent' Report for 'god'
ThingX ThingY CmnAnc Dist person john 100 3.14 god 2
Time Elapsed: 0.906550 msec
Please show Neo is a "fraud and a liar" by storing the equivalent of the following XDb1 script in RM Sol#1 or #2 without redundant data.
color isa thing.
brown isa color.
person isa thing.
john isa person.
john's color is brown.
mary isa person.
mary's color is brown.
Although brown appears three times in the script, XDb1 normalizes the second two by making them references to the first one. There is only one brown in XDb1's db. Using RM#1 or #2, brown is stored three separate times.
Thus far RM Sol#1 and #2 fail to meet the challenge because, they contain redundant schema (schema is data) to store the class hierarchy which cannot be accessed by the provided report procedure, and stores redundant data (ie "brown"). Deficiencies in the genericness of the solutions can be shown by the inability to handle things without an attribute (ie name) and things with multiple attributes each of different type, etc.
Below are measurements made thus far using RM solutions that aren't as generic or normalized as XDb1's.
Small Report Generation Summary (provided by Hugo)
Solution Time(ms) Platform Notes
-------------- -------- ----------------- -------------------------- RM#1 SqlSrvr2K 14.3 1.3 Ghz PC Unnormalized, non-generic RM#2 SqlSrvr2K 11.0 1.3 Ghz PC Unnormalized, non-generic XDb1 4.4.7 16 1.3 Ghz PC Debug ver, norm and gener
Small Report Generation Summary (provided by Neo)
Solution Time(ms) Platform Notes
------------- -------- ----------------- -------------------------- RM#1 SqlSrvr7 65.0 500 Mhz Server Unnormalized, non-generic RM#2 SqlSrvr7 68.9 500 Mhz Server Unnormalized, non-generic XDb1 4.5.7 1.632 500 Mhz Server Normalized, generic XDb1 4.5.9 6.561 233 MHz PocketPC Normalized, generic
Large Report (28,940 rows) Generation Summary (provided by Neo) 200 Goat Hierarchy (5 generations x 40 goats/generation, each goat having two parents, except 1st gen).
Solution Time(sec) Platform Notes
------------- -------- ----------------- -------------------------- RM#5 SqlSrvr7 40.5 500 Mhz Server Unnormalized, non-generic XDb1 4.5.7 2.9 500 Mhz Server Normalized, generic XDb1 4.5.9 16.971 233 Mhz PocketPC Normalized, generic
Larger Report (276,620 rows) Generation Summary (provided by Neo). 400 Goat Hierarchy (10 gen x 40 goats/gen),
Solution Time(ms) Platform Notes
------------- -------- ----------------- -------------------------- RM#5 SqlSrvr7 105 min 500 Mhz Srvr, NT Avg of 2 runs, UnNrm,UnGen XDb1 4.5.10 44 min 500 Mhz Srvr, NT Avg of 2 runs, Norm, gener XDb1 4.5.10 57 min 450 Mhz PC, 98 1 run, Normalized, genericXDb1 4.5.10 195 min 233 Mhz PocketPC 1 run, Normalized, generic
Note: SQL Server scripts are available from website. Received on Thu Jun 10 2004 - 18:55:11 CEST