<snips>
> 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.
Using an SQL server backend is like using Perl . . . you sacrifice some
efficiency in running, but make up for it in a big way in efficiency of
development . . .
Much easier to code in a high level language than assembler, much easier
to make disk structure alterations on a RDBMS than on a binary playerfile,
for example.
> > 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?
>
> Obviously a model which employs complete world persistence has a long way
> to go before its accessable to the masses. And even then there will
> always be things which are beyond their immediate comprehension. I was
> suggesting it as the most economical answer to the question of
> persistence.
World persistence might be a difficult thing for newbie implementors to
understand, but so are linked lists, playerfile converters, etc etc.
I think a world made persistent with SQL is easier to comprehend than the
current system where some information exists only in memory.
A mobile's in a room right now, but when the mud reboots it isn't
anymore? But why? ;-)
If it's incomprehensible to people who don't know what they're looking at
either way, you lose nothing by going with the way you feel is more
sensible.
All of this is IMO only, I'm not all that experienced at seeing the world
through the eyes of a newbie (I'd suggest that most of us aren't).
Chris
+------------------------------------------------------------+
| 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