On Wed, 12 Jul 2000, Daniel A. Koepke wrote:
>[n.b.: I never replied to this. I know it's old, but I kept it around
>with the intent of replying, and only just now got to it.]
Welcome to the club. :)
>> In any case, SQL itself isn't all that efficient.
>
>Again, efficiency isn't a big issue. SQL servers may not have optimum
>performance for our particular needs, but for the majority of our work
>they'll perform more than admirably. The slowdown won't be noticable to
>users in 99% of the circumstances, and the flexibility, ease of
>implementation, and well-known query syntax make it the best option.
What we may lose in efficiency (SQL query just can't compare to a pointer
dereference for speed), we gain with persistence state. No longer do we
have to load and parse the world into an internally usable format. In
addition, we're pretty sure that if we crash, we can simply pick up right
where we left off since we have a much lower probability of corrupting the
database accidently.
[Other points left out because I didn't have much to add to Daniel's
reply.]
--
George Greer
greerga@circlemud.org
+------------------------------------------------------------+
| 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