Database Options
Goto page Previous  1, 2
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  
Author Message
clink



Joined: 12 Aug 2006
Posts: 9

PostPosted: Fri Jun 15, 2007 10:54 pm    Post subject: Reply with quote

Kelvin wrote:

[*]Keeps the generic Object model... generic. Having to modify your table structure frequently is indicative of bad DB design.


This isn't entirely true. Having to modify your DB design (and code design) is often a matter of not gathering good requirements. You can design for maximum flexibility (for developers) or maximum performance but not both.

It seems as if you are looking to code a framework for muds rather than a specific mud, so you are likely to try to pursue the flexibility route. However, I'd caution against becoming too generic at the expense of performance of things which you have no expectation of ever changing.

As other people have stated, it makes sense to have something like a room table with the attributes of a room as columns. To add flexibility you can add an additional room attributes table which allows implementors of your codebase to add things with name/value pairs or something analogous.

Of course, you should mask the difference between those types of attributes from the actual users of the data (higher level pieces of code) though it'll make your job of coding harder.

At the end of the day this isn't going to remove all performance issues, it'll just defer them. But there's nothing better you can achieve in that respect if you are looking to remove database changes from your codebase users (IMHO).

clink
Back to top
View user's profile Send private message
Author Message
Kelvin



Joined: 08 Apr 2007
Posts: 10

PostPosted: Sat Jun 16, 2007 2:04 pm    Post subject: Reply with quote

Again, performance is not an issue in this case with such a light use application like a MUD. If this were to host thousands of concurrent users, yes, there'd probably be a difference. Since we had to make the same decision when designing our database, we tested and found there to be no tangible difference between these two models in terms of performance. This was tested using SQLite3 with the databases cached in memory.

People tend to micro-optimize too much, it's an easy mistake to make and it's how we end up with the "Gentoo Ricer" mindset. Shaving a few CPU cycles here and there at the expense of flexibility is just not worth it, especially considering the typical human can't see a difference in the end result. This is one such case where we as humans with a much less granular sense of time than computers, can't tell a difference and those handful of saved CPU cycles just won't mean anything.

And as far as for designing for both performance and flexibility, I disagree here. Not being able to design for both is often a sign of inexperience on the coder's part. Performance is a relative term, and in this case, the lack of visible lag and reasonable server resource consumption fall under the requirements. We're in the age of strong CPUs, large, cheap RAM, and fat connections, there's just no need to nit-pick about micro-optimizations anymore as long as the design is reasonable (which this is).

clink wrote:
Kelvin wrote:

[*]Keeps the generic Object model... generic. Having to modify your table structure frequently is indicative of bad DB design.


This isn't entirely true. Having to modify your DB design (and code design) is often a matter of not gathering good requirements. You can design for maximum flexibility (for developers) or maximum performance but not both.

It seems as if you are looking to code a framework for muds rather than a specific mud, so you are likely to try to pursue the flexibility route. However, I'd caution against becoming too generic at the expense of performance of things which you have no expectation of ever changing.

As other people have stated, it makes sense to have something like a room table with the attributes of a room as columns. To add flexibility you can add an additional room attributes table which allows implementors of your codebase to add things with name/value pairs or something analogous.

Of course, you should mask the difference between those types of attributes from the actual users of the data (higher level pieces of code) though it'll make your job of coding harder.

At the end of the day this isn't going to remove all performance issues, it'll just defer them. But there's nothing better you can achieve in that respect if you are looking to remove database changes from your codebase users (IMHO).

clink
Back to top
View user's profile Send private message
Author Message
clink



Joined: 12 Aug 2006
Posts: 9

PostPosted: Sun Jun 17, 2007 1:00 am    Post subject: Reply with quote

Kelvin wrote:
Again, performance is not an issue in this case with such a light use application like a MUD. If this were to host thousands of concurrent users, yes, there'd probably be a difference.


It sounds like you've set your requirements around flexibility. You've decided the tradeoff is worth the performance hit in this case. I agree it's probably an extremely small hit for data this size and well worth it.

Having implemented some non-mud systems at scale of millions of users and GB of data, there are significant cost advantages in the total cost of ownership to "micro-optimizing" certain pieces of an architecture.

It seems to me you've made the right design choice. Given completely different requirements in terms of scale, it wouldn't be. That was my only point.

clink
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign