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
some defacto libs out there for DBMS systems out there now, won't solve
the issue of another system out there who only supports ODBC (where
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
see the value of adding proprietary code when you can simply have "one
size that fits all" and compatability.
Just my nsho,
Mike
+------------------------------------------------------------+
| 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