| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: Shared game-data
Alvin Ryder wrote:
> 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?
>>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.
That depends on what one calls an array. A string is an array of characters, but you consider it an atom.
As long as the dbms' only access to the values of the type are through the operations defined on the type, the values are atomic.
Thus, a character string is atomic even if it has a substring operator that results in another string.
> 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*)
Thus, if an attribute contains an entire game state for a multiplayer game and the dbms cannot decompose the attribute, it is atomic. Not that I would recommend such a design.
> There's that word "atomic" again, frankly I don't have a problem with
> it.
Neither do I. I marvel that you can read the above passages and come to such wildly incorrect and obviously contradictory conclusions. That you then spread your ignorance with such conviction and certainty astonishes me.
>>>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.
Actually, you did. See above.
>>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.
So? Your assertion that the RM cannot provide this is just ignorance.
>>>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.
I replied that way because what you wrote is ignorant horseshit that doesn't merit any greater effort. You have in no way supported the ignorant horseshit you posted, and I have fully refuted it. Received on Mon May 01 2006 - 09:25:17 CDT
 |
 |