>Better than having a separate process specifically for managing world
>state through memory mapping, is to just use an existing database. For
>instance, MySQL or PostgresSQL or any other SQL server you might have
>available. These databases often offer rollback and other services, in
>addition to being relatively simple to switch platforms with.
Yes, but have you ever seen a database running under some form of comitment
control actually perform a rollback? It's not cheap by any measure. The
problem would be compounded by the fact that mud's database(s) would be in
far more of a state of flux than your average business's transaction files.
Try and rollback an update that occured simply 10 minutes ago, and the game
would probably somewhat unplayable for a time. (Not to mention the lights
in the room dimming, as the pc groans under the strain)
I'm not sure how other concepts such as referential integrity would play
out. Never gave any thought as to restructure of the mud's db in terms of
multiple header/detail files, etc.
In any case, SQL itself isn't all that efficient. Never was meant to be
more than a quick and dirty query tool to help give developers in an mis
shop some slack to work on other more important issues. eg, Programmer
Jones while working on changes to reporting for1099's and W2's gets a call
from the CFO who needs this report asap.
-jac 'I'd sure like to see how the no-code mud imps ,who have trouble
figuring out what the +/- mean during hand patches, handle being confronted
with things like the difference between inner/outer joins, etc! Are you
normalized? Huh?'
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT