On Fri, 2 Apr 1999 12:03:17 -0500, Michael Lemler <coronach@succubus.datacruz.com> wrote:
>To include a bunch of native database driver support for the mud would be
>insane. Each one usually has it's own API, so each line of code you
>generate has to be proprietary to the database system.. unless you write
>your own preprossesor. Future exapandablity is also hurt, simply slapping
This is somewhat true. Right now my MUD works with SOLID db. I may
switch over to Oracle. Which means re-writing my database library.
But, this isn't really that much code to re-write. SQL is transparent
from database to database, for the most part. Sometimes table creation
differents (int or number(), etc. etc.) but basic SQL remains the same.
>everything is going). ODBC is fast enough to do what MUD design had in
>mind. ODBC is fast enough for enterprise wide applications. I just don't
On the note of speed and ODBC. Many people will be surprised by how
_slow_ databases are when linked into the MUD. I almost scrapped all
of my work when I had just put in my database code.
The MUD works in .1 second increments. That's not much time to transmit
data to and from a database, espetially if you do this as they are currently
done (in mass every few minutes). It's also slow if you do things instantly,
as I do things now.
The way i sped things up is to create 2 database controlled threads
and have those threads do all update/delete/insert statements. This is
good because it's fast and transparent. It does prevent you from catching
errors in your functions that do the SQL.
As for select statements, I had to do some other crazy stuff with threading.
It's doable, but you've gotta do a lot to make it transparent.
- Anil
Anyway
+------------------------------------------------------------+
| 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 : 12/15/00 PST