The only thing I could see to save space is to have separate tables for each
attribute an object can have. So the actual object table just associate
players with unique items. Then you'd have an "effects" table, "values"
table, "costs" table, etc with just the object's unique id and the value for
that item.
If there isn't an entry in that table for the item, use the default.
It'd be more complicated and slower to load and save players than just having
an object table with an entry for *everything*, but it would save space. I'm
not sure what the exchange would be.
----- Original Message -----
From: "Dale" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 14, 2004 11:38 PM
Subject: Advice on how to do something in SQL
Ok I was wondering, I've been working on coverting some of my muds files to
an SQL database. This way I can add more features to our website.... So you
can control a little bit more from the site. For those who might not have
time to login to the mud. But need to agree to some invoices or what not.
My question is I would like to put the pfiles into the database. But the
problem I'm running into is the Objects, and Pets the player has.... Now I
realize I could make an object table and spill all the players objects into
that table. And store it by the ch_id and just call them in and out by
that.. But my problem with that, is won't that cause me to start taking up
more server space? Cause how objects works now it only saves whats changed
about the object... This would make it so the full object information was
being stored for each item.... IDK seems like a waste of space reallly...
Anyone have any advice on how maybe they cleaverly did their objects? I was
debating maybe still leaving a txt pfile and storing the recursive things
like objects in there.... But I figured I might ask to see if anyone else
had found a cleaver way to handle this.
--
ROM mailing list
[email protected]
http://www.rom.org/cgi-bin/mailman/listinfo/rom
