views:

129

answers:

1

I'm attempting to create a CakePHP based web game mostly for practice as well as for the fun of it, but am running into a conundrum trying to figure out an equipment system.

I have an Items table that contains all the possible information about an item, including an item_type field that contains an integer value determining what the item type is, and resulting, which information about the item to use.

i.e. item_type = '1' means that the item is a hat to use, which means that only power, price, bonuses, and requirements are necessary information. This all works fine.

I also have an items_users HABTM table set up in order to store all the currently owned items that each player has, this is also working fine.

What I'm trying to figure out is how an equipment system would work. I first thought about an equips table such as:

    CREATE TABLE `aevum_tf`.`equips` (
`id` INT NOT NULL ,
`user_id` INT NOT NULL ,
`hat_id` INT NOT NULL ,
`wep_id` INT NOT NULL ,
`offhand_id` INT NOT NULL ,
`pants_id` INT NOT NULL ,
`acca_id` INT NOT NULL ,
`accb_id` INT NOT NULL ,
`accc_id` INT NOT NULL ,
`shirt_id` INT NOT NULL ,
`created` DATETIME NOT NULL ,
`modified` DATETIME NOT NULL ,
PRIMARY KEY ( `id` ) ,
UNIQUE (
`user_id`
)
) ENGINE = InnoDB

The only problem with using a system like this is that CakePHP does not support multiple foreign keys for a model.

Does anyone have any ideas as to how to implement such a system?

EDIT The existing HABTM table of items_users is used to store which items a user currently owns. Every time a user acquires a new item, it's id and the user's id is stored in the items_users table. I'm just trying to figure out how to implement an equipment system.

By doesn't support multiple foreign keys, I mean CakePHP doesn't natively support multiple foreign keys from one table in another table. My example equips table has 8 foreign keys, all pointing to item_id's.

see: https://trac.cakephp.org/ticket/1923

+3  A: 

I've found that HABTM relationships are best for simple relationships, not complex ones like you are describing above. The idea of an HABTM relationship is to make the join table almost invisible so you do not have to maintain the extra foreign keys. It works well for simple cases.

In your case, you have the equips table that would join to all of the other aspects of your system. In the design, you need a starting point. I would imagine the "user" would be that starting point and the user would have many equips. You may limit a user to having only one equip, which would almost lend itself to merging the user and equips tables into a single one.

In any case you need to start by defining the rules.

User -> HasOne -> Equips Equips -> BelongsTo -> User

According to your database deisgn, it looks like the following relationships would be made. Equips -> BelongsTo -> Hat Equips -> BelongsTo -> Pant Equips -> BelongsTo -> Wep Wep -> HasMany -> Equips ...

To build the best application, what I would suggest is to build every possible relationship and look at the resulting data set from each view...

$this->User->recursive = 2; 
pr($this->User->find("first");

From there I would redesign the tables to get a structure that looks good and makes sense. Then trim out the unnecessary relationships.

Also spend some time looking into binding and unbinding models. This will allow you to more effectively customize the data and relationships once the database design is stable.

Hope this helps a bit.

Dooltaz
Yeah, I can't think of any other way of doing it simply, without a very complicated items to equips relationship. I'm probably going to split the items table into the different groups of item types instead, see how that works.
Aevum Decessus