Re: SQL Database Usage

Christopher Bunting wrote:

>Hello All,
> In regards to the reply that MrPotatoHead submitted, I thought I'd
>start a new thread and try to get things going correctly instead of
>adding on to the old burnt out thread.
>
>Before I go any futher, I'm going to say that most of this post is my
>thoughts and opinions, However, I also have years of experience with
>php/mysql..
>
>So to get to the point, I've seen allot of people saying what can and
>can't be done. And my first question is, Have you actually tried to
>use mysql for everything within Rom? It can be done with php and
>mysql, No doubt. But just to say it can be done in Rom, or any general
>diku deriv is a whole nother ball game. To get Rom to load everything,
>I mean areas, datafiles, player files, spells, skills, objects,
>mobiles, resets, and a spare db table to hold temp values for corpses,
>repops and other misc things, You are moreless talking about rewriting
>90% of rom as it stands. Just so we are clear, Everything loaded to
>db.. Leaving you with only .c/.h source files and a .sql db.
>
>The whole reason this all originates is because the standard diku
>derived mud loads everything into memory to be referenced/manipulated.
>(Unlike LPC) It's easy, fast, and it works.. But to go the only other
>route, would mean that you use a database, or plain c and simple
>generic IO functions to read and write to a text db.. The latter has
>been proven to smoke sql..
>
>  
>
>>>Personal Note: Since I'm a big fan of TADS, HUGO, IF Adventures and
>>>      
>>>
>so forth. Including LPC, I'd prefer using C/IO to read and write from
>text files..over SQL. It has worked for many, many years.. Discworld
>and tons of others are perfect examples.
>
>But that still leaves various issues in regards to SQL or MySQL.. I
>simply do not think that most people are knowledgable enough of C and
>SQL/MYSQL in general to be able to overcome the various issues.. Most
>wouldn't even know where to begin trying to load resets, mobs, objects
>which are dynamic data to an area and/or room that are dynamic as
>well. Then let them try keeping a corpse on a timer show for X amount
>of minutes in a dynamicly generated area/room when the players walk
>in.
>
>We are not talking about building a commercial CMS system built in
>PHP/MYSQL. These alone have to be designed in a fashion to output the
>needed data with the least amount of db queries to keep away from the
>undisputed killer called lag. Unless you are using more than one
>server to balance the load like sourceforge and so forth.. I still
>have yet to see a plain text mud that big using more than one entire
>server either.
>
>But the problem I see is that everyone talks about how easy it is..
>But the fact is, it's not easy. You are also talking about each player
>making 75 times more queries to the db than a standard user browsing a
>web site.. Can you imagine all of Aardwolf's players casting spells
>throughout the day.. Prolly hundreds of thousands of spells each day.
>Now think of that many db quries along with rooms, objects, mobs,
>spells, skills and everything else being queried from a DB. There's a
>reason why scripting engines are common in games like FarCry,
>EveryQuest and Baldur's Gate but database usage is not...However, A
>mud processes 50% more requests per user than any 3D MMORPG that I've
>ever seen.
>
>I honestly, in my experience still can not see where the end result
>would be useful for such a thing.. To simply claim that it makes
>adding extra data to areas easier is a bit... well, thats the same
>reason why you can open db.c and insert, load_mod_area and add the bit
>of code to load your cool new stuff. Then use save_mod_area to save
>your cool stuff for the next reboot.
>
>I've said to many people who asked me for ideas before to plan for
>further expansion. Even if you only plan on using 4 races/classes. Add
>5 extra spots to each table along with adding 5 to skills and spells.
>Add 5 extra sections to the area files if you think you're going to
>expand that much later on.. After all, Mud Development needs to be
>planned out, and have a foundation just like anything else being
>developed. MMORPGS don't just pop up. They are planned, schetched on
>paper, it's a long drawn out boring process,
>
>But overall, I still have yet to see any valid reason to waste extra
>resources just to use sql. Using sql doesn't make writing spells or
>the overall development of the mud engine itself any easier.. Fight.c
>can't be stuck in sql. So as a mud coder, you still have to do a fair
>share of coding, so why is a few modifications (5 minutes of work) to
>add new area/mob/obj data or room features so hard?
>
>I've searched the web high and low and I still, have yet to find any
>MMORPG or Mud that uses sql as a back end.. I see tons that are in
>development but none that I can find running with players..
>
>This is by no means to start a flamewar nor am I saying that using a
>DB simply can't be done.. But I'd like to learn more about this
>myself, see some examples and find some Production Muds w/ 100+ active
>players, who are actively using this concept.. If there is proof that
>it is proven and working, then I may look into it more myself. I'm
>always willing to do or try something new. But at this time, I see
>nothing other than a bunch of hearsay on every mud related forum I
>come across.
>
>If you know of or think otherwise, I'd be glad to hear it.
>
>Chris
>  
>


I see what your talking about, and I don't see why sticking things like 
spells, skills, fight code etc into SQL *IS* a
good idea. Things like the Ban list, Messageboards, Playerfiles (I have 
to say this here, I saw a snip somewhere
where it put all the pfiles into SQL and read them from there, this is a 
dumb idea, why not read the sql data then
load it into memory?) Areas, and specificly helpfiles being stuck into 
SQL, but everything else?
Lets face it, (using the skills loaded from a file thingy) Its pretty 
stupid to have to A) code the skill, B) increment the
MAX_SKILLS, then C) load the mud up, add it through an annoying command 
just to be able to use it. Youve already
done A and B, C should just be as easy, open up const.c, 
copy/paste/edit. These sorts of things shouldnt be
done in SQL, theres just no reason. Can you pull up Min/Max Damages from 
SQL? No, thats in the code, can you
pull up what effect and duration a specific spell does? No. Then theres 
no reason to add it to SQL. Infact IMHO
adding SQL to a rom based mud haphazardly is just flat out stupid. You 
end up hammering the SQL server
instead of quickly reading it from memory. (flush_connections anyone?)

There are only a few things I belive should be put into SQL for purposes 
of exporting it to a webpage, which
really is the only place you need the data elsewhere.
* Help files: Simple, add a search function for helps, link various 
parts of your page to the helps wiki style

* Ban List:   Its nice to have the Ban list in SQL, you can post it up 
on your website, people can petition a siteban for example

* Area files: While adding new areas isnt easier, it just allows you to 
create say a 'virtual' tour on your website. This can also be achived by 
dumping the files to sql instead of reading directly from it, also 
saving on SQL queries.
Possible HTML based Area editor? Have builders directly upload a 
finished non-your-mud area into sql? hmm

* Messageboards: Link your ingame notes to a e107/NukePHP Fourm. Cool eh?

* Playerfiles: Easy way to keep track of top10 lists, 'finger' commands 
(from ingame and webpage)

* Chat Commands: To view history ingame/on a webpage (Chat history 
webpages are cool ;)

Seriously, do you need anything else in SQL? Even Area files is a tad 
over the top. Unless the Data changes alot,
(not constantly like Player data, note i said playerfiles, not 
playerdata) like messages, ban lists, helpfiles, Why not
just write a function to create a Static HTML page with the information?

To finish, sticking everything into SQL is not a good idea, sticking 
things that could be useful in other places like say
websites is. Just a word of advice. Besides, What about Security? =)

-Thri




-- 
ROM mailing list
[email protected]
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom