[MUD-Dev] Complexities of MMOG Servers WAS Retention Without Addiction

[J C Lawrence]

On Thu, 12 Dec 2002 22:48:45 -0500
Derek Licciardi <kressilac at insightBB.com> wrote:

> ps This brings me back to my database post.  Why on earth would you
> place this somewhat-inexperienced talent on database code when that
> wheel is already well formed and optimized by thousands of capable
> professionals working on large scale DBs?  It seems that the custom
> game-server code would be more important because no one is going to
> write that for you.  Writing your own DB has to be a waste of time
> from that viewpoint.

Database != database.

A database is a tool.  A database of a specific type is a tool suited to
specific types of problems.  Not all database problems are suited to
resolution by an RDBMS.  Not all database problems are suited to
key/tuple retrieval systems.  Not all relational data problems are
suited to modeling by an RDBMS.  Many object database problems model
extremely poorly in OODBMS systems (eg runtime morphic or dynamic
inheritance systems).  Many "database problems" model extremely poorly
in any of the standard database approaches or models, no matter the
type.  The list goes on, as does your list of requirements for your data
system.  At some point, ideally, they match.  If they don't match you
try and make sure that the delta is neither fatal or excessively
constricting.

Companies and products live and die by the accuracy of that choice.
Impedance is a bitch.

Often you don't know in advance.  Not infrequently you find out
retrospectively that you could have devolved a non-standard data
modeling problem into a standard form given the benefit of hindsight and
the simple fact that you now understand the problem space and its
trade-offs better than you did then.  It goes the other way too; less
often, but it does.  Them's the breaks.  Your job is to pick your
battles and breaks.

You pick your poison.  Sometimes, of necessity, you compromise.
Sometimes that compromise means you write your own. C'est la vie.

Again, you pick your poison.

  In my professional life I'm writing a database of sorts.  Even better
  I'm not only writing a database, but I'm also writing a custom query
  and report language.  Obviously this is insane, or is it?  As I'm
  working at a stealth mode startup I can't divulge much in the area of
  requirements or constraints but I will note that SQL of any form
  doesn't work worth a damn when you're trying to do even very
  soft-realtime matching of attribute constrained patterns.

Every tool has its uses.  None are universal, even on their home turf.
Typically I find it more important to know when to not use a tool than
knowing when to use it.  I find this one of the better clue detection
systems: "Okay, you're an expert_in/fan_of XXX.  When shouldn't you
use/do XXX?  When is it the wrong approach?"

As a principle this applies to technical and non-technical areas.

  PS Its rare that I find an OOA/OOD fan who can answer that question
  with an instance.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.


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