Re: Shared game-data
Date: 30 Apr 2006 22:26:06 -0700
Message-ID: <1146461166.502899.183880@i40g2000cwc.googlegroups.com>
Bob Badour wrote:
> Alvin Ryder wrote:
>
> > Alfredo Novoa wrote:
> >
> >>>In business systems it is desirable to normalize the data, lets just
> >>>discuss first normal form, all attributes are atomic.
> >>
> >>>OTOH game objects contain some atomic types but they also contain
> >>>pointers, other objects, trees, collections ... which is all very
> >>>non-atomic and very non-normalized.
> >>
> >>Wrong. It is evident that you don't know the Relational Model very
> >>well. That's why you don't see its relevance in game programming, which
> >>is evident for people with a good understanding of the RM like Bob and
> >>Marshall.
> >>
> >
> > Alfredo, exactly which part is wrong?
> >
> > Are you saying the RM does not advocate normalization?
>
Thanks for your reply Bob.
> Everything beyond 1st normal form is a direct application of the RM to
> certain problems of data management; however, the relational model does
> not in any way require them. Ignoring normalization is just a stupid way
> to make expressing one's needs difficult.
>
>
> > Are you saying first normal form doesn't require atomic data?
>
> Define atomic.
>
Nevermind my definition, let me such borrow Codd's: (Dec-1979 "Extending the Database Relational Model to Capture More Meaning") pp 399
"A domain is simple if all its values are atomic (nondecomposable by the dbms)."
A nondecomposable attribute is what I mean by atom. An integer or string is an atom, an array is not.
Codd also says (pp399):
"A relation then consists of a set of tuples, each tuple having the same set of attributes. If the domains are all simple, such a relation has a tabular representation with the following properities.
1. There is no duplication of rows (tuples). 2. Row order is insignificant. 3. Column (attribute) order is insignicant 4. *All table entries are atomic values*."
(Emphasis *mine*)
There's that word "atomic" again, frankly I don't have a problem with it.
>
> > Are you saying objects used in games, or any OOP, don't need to contain
> > references to other objects, trees or collections?
>
> At the logical level? No, absolutely, not. They do not need them.
Fair enough (I never thought or stated otherwise).
> Translating a correct logical description to a performant physical
> layout will use references and a variety of physical structures, but
> that is a completely separate concern.
>
But that separate concern is the one I have, maximum performance at the physical level.
>
> > If I'm wrong I'll admit it but why don't you show me the errors and
> > provide the corrections?
>
> I provided some corrections. However, none of the details you introduced
> to confuse the issues affect the liberal way you spread ignorant horseshit.
You haven't provided any corrections, you just
1. asked me to define "atomic" (I borrowed from Codd), 2. made a point about logical and physical independence, 3. make aspersions about me confusing the issue. # The original point I made several posts ago was:- # "The RM is powerful enough to represent business data, it rocks the # business world but it utlimately lacks computational power and # conviction to go all the way in every realm." #
# You replied
# Horseshit.
Some examples:-
- RULES We want to build an expert based system based on *rules*. For instance IF building_on_fire THEN walk_to_exit, then_run_fast.
We don't just want to insert tuples with key and non-key attributes we want rules.
What provision has the RM made to represent and them compute with such a rules?
2. SPATIAL computations.
EASY: "List all the customers who spent more then $10 today"
HARD: "List all the customers that live within 10 miles of the shop"
I could go on but you guys haven't answered any of the questions, are you even aware that the RM has some weaknesses?
Cheers. Received on Mon May 01 2006 - 00:26:06 CDT
