MySQL... 2004-08-20 - By Richard Lindsey
Back
Hi everyone, I'm contemplating making a slow changeover to using mysql
to store area and pfile info... I've heard some pros and some cons, the
cons mainly being the pain in the ass that it can be, the pros mainly
being performance gains, but while I'm toying with an initial database
setup to hold mob_index_data, a thought occurred to me... some of these
fields are arrays or linked lists of things, such as mprogs that I have
installed, and if and when I decided to do pfiles, things like their
skill list... does anyone have a suggestion on how to handle lists of
items in a database environment? It occurred to me that I should
probably set up a secondary db for mprogs and use a mob_index vnum value
as a foreign key, so that I could have listings like so:
mvnum mpvnum trig_type trig_phrase
3054 3054 speech heal
3054 3055 grall
3011 3011 grall
3011 3012 speech help
etc, etc... I'm sure you get the idea... keep a listing of mob vnums
associated with mprog vnums, and the type and phrase that trigger
them... but then I thought about how I'd need a database to hold
strictly mprog data, such as the code behind the mprog, and so I guess
what I'm trying to figure out is, is there a better suggestion out there
for what I'm trying to do, besides making 3 tables, one to hold
mob_index_data with a primary key of vnum, one for mprog_data with a
primary key of vnum, and one to hold mob_mprog_associations with foreign
keys for both vnums, for this scenario? Do I even have that straight in
my head? Any help would be appreciated :D
wavewave
Richard Lindsey.
--
ROM mailing list
ROM@(protected)
http://www.rom.org/cgi-bin/mailman/listinfo/rom
|
|
