On Sat, 2005-04-09 at 12:32 -0400, Christopher Bunting wrote: > Hello, > Well, scripting made it so that data could be manipulated on the fly > without the need to have to recompile and reboot. With that type of > scripting, you could manipulate everything all from within the mud > itself. > You can't do that with loading to memory or with using sql, > pgsql, mysql or any others.
I removed the bits about lua etc - Yes the scripting is seperate from a db, however there is a difference between using a DB as storage and a DB driven mud, those scripts would eventually need to be flushed to disk or everytime there was a crash of the process(es?) they'd lose everything. Don't need to make a difference between DB and anything else here, they aren't the same but for general design ideas it won't matter what it is (sql, berkley, anything else). This thread is about SQL database useage, correct? Let me attempt to get it back on track here - DB Driven vs DB storage Recently this made me think of ACM (A C MUD) "ACM is written in C, and uses MySQL to store all data for the mud. However, all objects, creatures, rooms, etc are still loaded into memory; this is not a DB-driven mud." That pretty much sums up DB storage to me. DB Driven on the other hand would be where all the manipulation that happens in memory would be done to the database. Currently most muds use flatfiles as thier storage, and use alot of specialized code to read/write stuff out to these files, it's easier for some to let another API handle all those. The biggest bonus to DB storage is allowing you to view/modify stuff easily external to the mud. mud's forums sharing username/passwords, webbased editors, stats etc are simplier to do using something other than stock flatfiles. -- Chad Ziccardi [EMAIL PROTECTED]
