Re: Shared game-data

From: Alvin Ryder <alvin321_at_telstra.com>
Date: 30 Apr 2006 22:26:06 -0700
Message-ID: <1146461166.502899.183880_at_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:-

  1. 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 - 07:26:06 CEST

Original text of this message