February 1998
- OT: Following in the footsteps of JCL Alex Oren
- OT: Following in the footsteps of JCL Nathan Yospe
- OT: Following in the footsteps of JCL Richard Woolcock
- OT: Following in the footsteps of JCL Chris Gray
- OT: Following in the footsteps of JCL coder@ibm.net
- OT: Following in the footsteps of JCL Marc Eyrignoux
- Ada? Andrew C.M. McClintock
- Monthly FAQ posting Koster, Raph
- Monthly FAQ posting Adam Wiggins
- Monthly FAQ posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Chris Gray
- Monthly FAQ Posting Ling
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting Alex Oren
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting s001gmu@nova.wright.edu
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Koster, Raph
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Marian Griffith
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Ling Lo
- Databases Shawn Halpenny
- Databases coder@ibm.net
- Databases T. Alexander Popiel
- Databases Dream Weaver at home
- Databases Laurent Bossavit
- Databases Kevin Littlejohn
>>> "Laurent Bossavit" wrote
> [On databases in general]
>
> I wouldn't use MySQL - the fastest SQL database around - for a MUD.
> It's optimized for ultra-frequent fetches of small to medium large
> chunks of information; our databases services 50 queries/sec and
Hrm. I'd have said that ultra-frequent fetches of small to medium chunks
of info is pretty much exactly where a mud sits. Of course, that depends
really heavily on _what_ you're using a database for. If you're using it
instead of file storage for characters, then it probably doesn't matter
_what_ you use. If you're using it to hold all your live game data, then
things get a bit trickier...
MySQL seems to work out nicely for us - admittedly, I've yet to see a
strain on the thing, but from what I've seen, I've got no concerns there.
What it _does_ lack, however, are transactions, and sub-selects - both of
which would help considerably in design ;)
Others: gadfly (python-based, if you know the layout of your tables it's
probably fastest, but equates out to having all data in memory at all times),
mSQL (dunno, haven't looked at it for a long time), Oracle (overblown,
slower than MySQL, but by $DIETY it does everything, including 'connected
by', which would be a _joy_ to use - provides for object hierarchies really
nicely), PostgreSQL (which _does_ look nice, and has some nifty tricks that
may help on the OO side... But which I couldn't fathom large object/blob
support for, so I gave up early). The list goes on, of course... ;)
> about a quarter of a gigabyte. It all fits on one (admittedly beefed
> up) machine. But I wouldn't use any of the "big" databases either;
> they are optimized to scale to terabytes of data, with robustness and
> consistency of the data given much higher priority than performance.
Again, I suspect it depends on what you're aiming for. Transaction support
under Oracle would be a godsend - kiss locking issues goodbye, pretty much,
if you plan things out right data consistency is a non-issue. Also, Oracle
does nice distributed database tricks - if you're willing to spend the
dollars for your mud ;)
> Fact is, I wouldn't consider using an SQL database for a M* type
> application; it's too much of a pain to map SQL records to the object
> oriented data used in most such software. My wish would be for a
This, I almost agree with ;) I have a layer set aside in Moebius that
maps SQL to OO, and it's a right pain. In addition, the quickest way to do
some things is no longer the obvious way - when the rest of your
programming world is OO-based, to suddenly discover that queries across the
mud (to find a particular type of item, for example) can be done much
quicker if you acknowledge the underlying non-OO-ness of the data store -
well, it throws an abstract spanner in the abstract works, if that makes
sense ;)
> native XML data store, with the ease of use and top-notch performance
> of MySQL, and a query language as useful and usable as SQL. This
> would be perfect for a MUD, and in fact many other types of
> applications - with a good XML database you don't need SQL, you don't
> need an OODBMS (XML-Data bindings do the OO part, the data store does
> the dirty work), you don't need much of anything. Unfortunately there
> isn't such a thing out there yet.
There _are_ OO-specific databases out there - Oracle have recently (with
8i, I think) started adding an OO layer to their stuff, so you can treat
things as 'objects' inside the db, and let oracle work out how to map that
best. That's hackish, I suspect, but presumably works into their XML
support as well. Would not the OODBMS's of this world put you a good way
toward this?
My attitude is still that databases do some things really well - storing
data, and for relationals, working out what links to what - and while they
may not be _ideal_ for muds, the chance of any given mud thrashing any
given database is still pretty slim at the moment. It seems as though db's
are generally a win over flat text files, so even if you use them as a
strange sort of disk space, they're a win - let alone abstracting and
playing with some of the other tricks they'd allow.
>
> Sigh.
What he said ;)
KevinL - Databases J C Lawrence
- Databases Kevin Littlejohn
- OT: This is a test coder@ibm.net
- OT: This is a test Alex Oren
- Clients and things [Was: OT: This is a test] Matt Chatterley
- Clients and things [Was: OT: This is a test] coder@ibm.net
- Clients and things [Was: OT: This is a test] Matt Chatterley
- MUD Development Digest Dr. Cat
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Felix A. Croes
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- DBs and Events s001gmu@nova.wright.edu
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- (subject missing) Ben Greear
- META: Unsubscribed users dur to bounces coder@ibm.net
- META: Unsubscribed users dur to bounces Adam Wiggins
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Richard Woolcock
- Source Code Release Ben Greear
- Source Code Release Chris Gray
- Source Code Release Greg Munt
- Source Code Release coder@ibm.net
- Source Code Release Richard Woolcock
- Source Code Release Stephen Zepp
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Travis Casey
- Source Code Release Jon A. Lambert
- Source Code Release Jon A. Lambert
- [RESEARCH]MUD articles archive (fwd) Greg Munt
- Socket programming (Was: The impact of the web on muds) Jon Leonard
- Socket programming (was: The impact of the web on muds) Vadim Tkachenko
- Socket programming (was: The impact of the web on muds) Richard Woolcock
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- user-centered design (was Clients) Mike Sellers
- OT: Linux g++ Greg Munt
- OT: Linux g++ Ben Greear
- OT: Linux g++ coder@ibm.net
- OT: Linux g++ Shawn Halpenny
- OT: Linux g++ Chris Gray
- OT: Clients Vadim Tkachenko
- OT: Clients Adam Wiggins
- OT: Clients coder@ibm.net
- META: OS wars coder@ibm.net
- META: OS wars Mike Sellers
- Clients Stephen Zepp
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Adam Wiggins
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Mike Sellers
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) Ben Greear
- Moore's Law sucks (was: 3D graphics) Ling
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Alex Oren
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Jon A. Lambert
- Version Control (was: DBs and Events) s001gmu@nova.wright.edu
- Version Control (was: DBs and Events) Raph & Kristen Koster
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Felix A. Croes
- Net protocols for MUDing (was: Moore's Law sucks) Jon Leonard
- Net protocols for MUDing (was: Moore's Law sucks) coder@ibm.net
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Caliban Tiresias Darklock
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Ben Greear
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Jon A. Lambert
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- VEIL (was: Clients) Brandon Gillespie
- LDMs (large dynamic maps) was Unique items Mike Sellers
- Describing the environment Stephen Zepp
- Describing the environment Richard Woolcock
- Back on the list Niklas Elmqvist
- Back on the list Chris Gray
- Back on the list coder@ibm.net
- Unique items The Eternal City
- Unique items coder@ibm.net
- Position sorting Adam Wiggins
- Position sorting coder@ibm.net
- Unique items coder@ibm.net
- Unique items Nathan F Yospe
- BOOK: Myer's Silverlock coder@ibm.net
- BOOK: Myer's Silverlock Chris Gray
- BOOK: Myer's Silverlock Adam Wiggins
- Dynamic Loading of Modules (was: Back on the list) Niklas Elmqvist
- Dynamic Loading of Modules (was: Back on the list) Vadim Tkachenko
- Dynamic Loading of Modules (was: Back on the list) J C Lawrence
- Dynamic Loading of Modules (was: Back on the list Jon A. Lambert
- Net protocols for MUDing s001gmu@nova.wright.edu
- Net protocols for MUDing Stephen Zepp
- Net protocols for MUDing Chris Gray
- Net protocols for MUDing Adam Wiggins
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Shawn Halpenny
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Chris Gray
- Dynamic Loading of Modules Niklas Elmqvist
- Senses (was: The MLI Project) s001gmu@nova.wright.edu
- bar-time (was The MLI Project) Mike Sellers
- 3D engines for MUDs (was: The MLI Project) Niklas Elmqvist
- 3D engines for MUDs (was: The MLI Project) J C Lawrence
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- 3D engines for MUDs (was: The MLI Project) Miroslav Silovic
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Cynbe ru Taren
- Why not compile java into object code? Caliban Tiresias Darklock
- Why not compile java into object code? Nathan F Yospe
- Why not compile java into object code? Niklas Elmqvist
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Jon A. Lambert
- Why not compile java into object code? Travis Casey
- Why not compile java into object code? Chris Gray
- Tutorial: Comments on Hand-crafting a compiler Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introduction Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part II: Expression Parsing Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introductio Chris Gray
- Tutorial: Let's build a Compiler! - Part I: Introductio s001gmu@nova.wright.edu
- Tutorial: Let's build a Compiler! - Part I: Introductio coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Koster, Raph
- MUD Development Digest Mike Sellers
- Tutorial: Let's build a Compiler! - Part III: More Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IV: Interpreters Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part V: Control Constructs Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VI: Boolean Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Comments Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VII: Lexical Scanning Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VIII: A Little Philosophy Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IX: A Top View Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part X: Introducing TINY Jon A. Lambert
- Compilers: Toy available for ftp Chris Gray