in reply to [untitled node, ID 308077]

One major benifit of combining items/weapons/armor into one table is that then you code for one and you have the rest. It also makes it easy to add new classes of items later on. In that way it at least makes sense as to why you combined them all together in the inventory feild, then you don't need much modification to store/inventory code in order to add new classes of objects.

I do become more and more interested in why there is as yet no module that allows you to store items with meta data (like armor bonus, attackt bonus...ect, different attribs for each item) in a database. I know that outlook already uses some system that allows it to store different peices of information for each item in its lists. It seems like it shouldn't be to hard to wrap something around DBI that would handle the special needs of handleing the extra tables and links, and building the required queries.

/me wonders off to cpan to see if there isn't a module already


___________
Eric Hodges

Replies are listed 'Best First'.
Re: Re: Efficiency MySQL question
by simonm (Vicar) on Nov 18, 2003 at 20:50 UTC
    I do become more and more interested in why there is as yet no module that allows you to store items with meta data (like armor bonus, attackt bonus...ect, different attribs for each item) in a database.

    I do this all the time, using standard database modules.

    The two primary tactics I use are:

    • Meta-data goes in a separate table, with columns for base object ID, attribute ID, and value.
    • Meta-data goes in a hash that automatically gets packed and unpacked with something like Storable as it's fetched/inserted.

    Both work, with some degree of tradeoffs in terms of performance under different types of query regimens.

[reply]

      I have two particular projects that each use one of those tactics. The problem with the first is speed and query building (not hard just has to be done) and the second hides that data away where it can't be easily queried. It would be awesome to have a module that gave you answers in a hash, let you edit it, and then put it back into its prospective parts of tactict 1 (for lack of better nameing). Of course then you have to deal with more complex data structures than a hash, arg, the whole thing quickly grows out of hand. Any ideas? Should this be a new topic or am i all alone here? :)


      ___________
      Eric Hodges
[reply]
        The problem with the first is speed and query building ... and the second hides that data away where it can't be easily queried.

        Yup. I'm using metadata tables for cases in which most of the information is stored this way, and packed hashes for cases in which most of the data is in normal columns and only a few extras need to be packed away.

        While I do think this technique is useful, I haven't yet found a way to abstract this into a general-purpose solution.

        Both kinds of implementation are reasonably easy to code as a layer over one of the standard RDBMS-OO mapper frameworks, like Class::DBI or my own DBIx::DBO2.

[reply]
Re: Re: Efficiency MySQL question
by CountZero (Bishop) on Nov 18, 2003 at 20:46 UTC
    Storing such variable meta-data seems like a job for XML. Unfortunately there is not yet a fast XML-based database available.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

[reply]

      In that case, just make a BLOB field (or whatever the equivilent is for your database) and put XML into it. Though that will make it slow to do searches based on that data.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

[reply]
[d/l]

In Section Seekers of Perl Wisdom