[MUD-Dev] The effects of object oriented servers on the item database (Long)

[Derek Licciardi]

> -----Original Message-----
> From:Chambers
> Sent: Tuesday, May 08, 2001 12:11 PM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] The effects of object oriented servers on the item
> database

> How would you implement a database for the object hierarchy?  Since
> each derived object would have different properties, you would need
> very large databases, right?  Does anyone have any tricks or
> articles about this? Maybe even an example?

The answer to this problem isn't quite as obvious as the question.
Will you be using a relational database, and object database or an
object-relational database?  Do you have the funding to get a real
database or are you stuck with a freeware or shareware database?  Both
of these questions have significant ramifications on your ability to
implement a database to support the object hierarchy.

  Relational Database: This is the most well known database out there.
  It is the most stable, has a reasonable level of tools that can
  access it and is probably the easiest to find qualified talent for
  administration.  On the flip side, the number of tools can confuse a
  project planner.  Do I use Borland Database Engine, ADO, a custom
  access layer, or Embedded SQL.  In addition to this, the object
  oriented nature of the object's ingame representation doesn't
  intuitively fit into a relational database system.  The objects have
  to be translated to this format and the design process required can
  lead to bad database design.  Try your best to find a qualified
  data-modeler before you attempt to use a relational database.

  Object Database: These databases provide the cleanest representation
  of the data.  It can be set up to be a mirror image of the in-game
  representation making retrieval and insertion a simple task.  On the
  flip side is a lack of tools, resources with experience, and the
  general immaturity of these database in the marketplace.  For that
  reason you will more than likely be on your own when implementing
  one of these.  If you can find the talent it may be your best
  solution.

  Object-Relational Database: You would think that this is the best of
  both worlds.  Properly implemented it can be, but the lack of
  expertise in the field is astounding for these types of databases.
  Not only does the person have to know a significant amount about
  relational design, they have to understand OOD as well.  Beyond that
  they need to know how the two relate and how to know when to use
  which style the most effectively.  I have yet to meet anyone in my
  career that can do this effectively, including myself.  While I
  consider myself strong in relational design, and good at OOD, you
  nearly have to be strong in both these to be the least bit effective
  with this type of database.  At present one of the only databases to
  allow this is Oracle 8i and Oracle 9i, so if you can not afford a
  real database this is not even an option for you.  If this is an
  option, you get the benefits of the availability of tools along with
  the easier representation of data in the database that the above two
  model provide.  Given the talent this can be a very powerful
  solution.

If you can afford it, get SQL Server 2000, Oracle 9i or some other
robust database.  Your administration nightmares will be lessened and
the platform will not require as much shoehorning to get it to work
with your toolset.  I have found that on Windows platforms SQL Server
2000 with ADO is a very powerful tool.  On Unix you are stuck using
Oracle or DB2 and Embedded SQL.  These tools are not as user friendly
though some would argue they are far more powerful.  As a certified
DBA for both Oracle 9i and SQL Server, I can tell you that each has
its strengths and weaknesses with respect to development.  Oracle
tends to be more scalable, though it costs more and is only more
scalable on Unix platforms.  On NT/Win2K they are roughly equivalent.
SQL Server tends to be easier to develop for on a windows platform.
ADO, ASP, COM and other OS Services are better integrated into the
development environment than is the case with Oracle on windows.

As for handling multiple object derivations in a database, I am going
to assume you will be using a relational database and that you will be
using the database as a storage system in place of the traditional
file system approach most MUDs take.  This explanation does not
attempt to provide structures for all MUDs nor does it attempt to
provide structures for realtime in-game management of the data.

The first thing I would do is draw what is called an ER diagram to
desribe your data.  Entity Relationship diagrams define how 'Entities'
relate to one another which allows easier transformation into a
physical storage design to be implemented into the relational
database.

The first thing I do is define all my entities:

  Objects
  Object Types
  Object Affects
  ...

The second thing I do is I define how each of these entities is
attributed.  Objects

  Name
  Description
  Value
  Rent
  Strength
  ...

  Object Types
    Type Name
    Description

  Affect Types
    Affect Name
    Description
    Stat
    Modifier
    Duration

The third step in the process is to define the relationships between
each entity.  You define these by stating how each entity relates to
one another in cardinality and in optionality.  Entities can have one
of the following four relationships:

  Optionality      to       Cardinality
    One            to         Many
    One            to         One
    Zero           to         Many
    Zero           to         One

I would use the following relationships to define the entities above.

  1) Objects must be of one and only one Object type (one to one)

  2) Object Types may define one or more Objects (zero to many)

  3) Affect Types may be assigned to zero or more Objects(zero to many)

  4) Objects may have zero or more Affect Types(zero to many)

When this is translated to a physical table structure, Objects becomes
a table, Object Types becomes a table, Affect Types becoems a table
and an additional table is created during the process to resolve the
many to many relationship that exists as a result of the two zero to
many relationships on Affect Types and Objects.  This table is called
Object Affects.  In the Objects table a foreign key would be setup and
liked to the Object Types table.(This adds an attribute Type Name to
the Objects table) In Object Affects foreign keys would be setup to
link the table with both the Affect Types table and the Objects table
such that the entire table forms the primary key for that reference
table.(adding the appropriate attributes to the table)

Install this into your database, write the scripts and layers
necessary for your code to work with this layout as defined by your
choice of tools and you will be able to store objects of nearly any
type by adding additional types to the Object Types table and then
defining the objects as a row in the Objects table.  You will want to
write some tool to help you manage all of the meta-data (data that
describes data) in your system like Object Types and Affect Types.
Once the data is in this format it can then be analyzed by your team
to accomplish balancing and other such tasks much more easily.  I hope
this helps to answer your question.

Before you run off and think about designing your own relational
database, I need to warn you that you will encounter difficulty in
deciding how to store objects that have varying numbers of parameters
to their functionality or have a hierarchal relationship to other
objects.  There are numerous books on proper relational database
design.  Unfortunately there is no best way to do it as each decision
has its tradeoffs.  Learn about them and make the decision that best
suits your individual needs.  The example I have given here is
extremely simplistic and assumes that all your affects have the same
types of modifiers.(ie +/- some stat or another) In addition, all of
my Object types in this case would be mutually exclusive of one
another.  If this is not the case further tables will be needed to
describe the relationships between object types.  Good luck and please
feel free to email me directly with any design questions you may have.

Sincerely
Derek Licciardi




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev