>> <a rel="nofollow" style='text-decoration: none;' href="http://www.xdb2.com/Example/Ex030.asp" target="_blank">www.xdb2.com/Example/Ex030.asp</a> shows ...
>> different things are named by just
>> one string 'brown' which has the ID 2EFB.
>
> illustrates your poor separation of logical/physical concerns,
> despite your claims to the contrary.
> That 'ID' is a physical artifact.
What it illustrates is your poor ability to evaluate information for a
particular purpose which was to determine if multiple things with the
same name refer to the same string in XDb2. Not that it would be a
typical method, but the sure-est method to verify if two things are the
same is by comparing their physical location. Exposing that different
things (a person, a color, a street) refer to ID 2EFB (string 'brown')
for its name is a surer means to verify non-redundancy than via
information provided by a higher level interface. For example, if a RM
view displays that a person is named brown and that a street is also
named brown, it is not as easy to determine if the two strings are
different or refer to just one. Just because I actually showed you the
physical blinkers of a car versus those displayed on the dashboard,
does not in anyway reduce/increase the separation to hardware provided
by the instrument panel (ie SQL/NLI). Please review XDb2's scripts for
any examples including that for 'Troy' and observe that no IDs are ever
exposed. Please post RM's equivalent script/queries WITHOUT IDs!
> You obviously don't know what declarative means.
You might want to compare to XDb2's script to that of RM's for a person
named 'John' who is male. Please post RM's equivalent script/queries
for city and quarterback named 'Troy' (or almost any other XDb2
example) so one can verify which is more declarative. So far, you have
NOT posted ANY verifiable scripts to support your assertions.
> I've been able to discern the following distinct
> access paths in your product: + meta data to user data...
Could you pin-point this in one of the XDb2 scripts posted thus far and
also post RM's equivalent script which doesn't?
> RM has one.
XDb2 has two, one high-level and one low-level. Each has it's
advantages and disadvantages. Can you demonstrate some advantages of
having only one?
>> Second, suppose Terrorist take over the US. As part of
>> their spoils they demand you and I reverse the spelling
>> of every thing named 'Troy'.
>
> That's all you have ...
It only takes one.
> ... a ridiculous example?
While a person might judge an example to be "ridiculous", it shouldn't
prevent a data model from being able to model/manipulate the data as
such. See "A Normalization Question" for other less "ridiculous"
examples. Apparently your experiences in data management are limited in
scope if you haven't yet come across situations where the unimaginable
becomes reality.
> No one would arbitrarily change *all* references to a specific
> value into a reference to another value (such as, the number 2
> into the number 1492) in any but the simplest db and expect
> to retain usable data.
Again, while a person might judge that no one would perform a certain
operation, it shouldn't prevent a data model from being able to do so.
Such restrictions should be built in the app layer not the db layer.
Apparently your experiences in data management are limited in scope if
you haven't yet come across situations where the unimaginable becomes
reality.
> Duplicate facts cause corruption...
Yes, and the string 'Troy' is a fact as much as a quarterback or a city
is a fact. See RM example posted earlier where Male is a "value" with
respect to John, is also a "fact" just as much as John. In the example
below, it is rather obvious to deduce that within the constructs of RM,
Male is just as much a "fact" as John is a "fact" even if Male is a
"value" with respect to John and Bob.
T_Gender
ID Name Abbr
1 Male M
T_Person
ID Name GenderID
2 John 1
3 Bob 1
> Duplicate values are needed
> (Sam has 2 children; Mary has 2 children.)
ARE YOU READING WHAT YOU ARE WRITING? One does NOT need duplicate
things in a db. It is redundant. It can lead to corruption. "Values"
are not duplicated in XDb2 and duplicate value can be eliminated in RM
by employing generic modelling (which is not always practical). See
example above, where both John and Bob have the same "value" Male
without redudancy. (No the ID 1 is not redundant data! See "A
Normalization Question")
>> Third, suppose we want to add an attribute to the string 'Troy'.
>> In XDb2, it would be simply (CREATE 'Troy'.point value = 15).
>> In RM, you will need to change the schema to normalize all the
>> redundant 'Troy's so that the attrubute can be added
non-redundantly.
>
> Actually, assigning an attribute to heterogeneous references
> to a value is likely cause integrity problems.
In XDb2, the attributes are assigned to the one and only "value" not to
references to the value. The same can be accomplished in RM using
generic modelling (which is not always practical). See example above
where the attribute abbreviation is added to Male which is both a
"fact" and a "value" in RM speak.
>From the example I gave earlier where "John isa Person" and "John is
Male" and "Male isa Gender", you still have not yet realized that while
Male is a value with respect to John, Male can have it own attributes
for example "Male is a Gender" or "Male is abbreviated as M" or "Male
point value is 8". Just as Male is a value with respect to John, there
are other things that are values with respect to Male. It is recursive.
Please read "Godel, Escher, Bach: An Eternal Golden Briad". Please post
RM's equivalent script/queries for that modelled by XDb2, irregardless
of your personal judgements about particular data or operations.
> Get serious!
> There is a wealth of information available on those aspects of RM.
Please post some verifiable scripts/queries to support that wealth of
information.
> In this short article I've already shown that you have an ad-hoc
> organization, information is not guaranteed accessible, integrity
> and usability are not perserved and your query facility is not
> declarative.
You have shown nothing verifable in this short article. Please post
equivalent RM's script/queries for city and quarterback named 'Troy' to
support your assertions.
>> Stay informed about: Help Understanding OODBMS' 
FAQ
Search
Profile
Private Messages
Log in
