Database design

it’s still on delay but it’s coming. i recently started myself on a new schedule to get more programming done but it leaves less time to write, but as soon as I finish it I will put it up.

Anyways in the mean time, I want to hear your views on database design and how much effort you put into it. I am currently in the phase where I am mapping out my databases. The way I do it is that I create the db then start writing skeleton scripts that mimic the way the game engine is going to work. Then after all it is sorted out I will just fleshing out the skeleton scripts with actual info from where it’s supposed to coming from.

But I think I spend a good amount of time trying to create my databases in an efficient way, aiming for at least 3NF(third normal form) . How much emphasis do you put on your db design?

10 Comments

  1. Considering that database design will be central to everything else that is coded, having it planned out properly in advance, with enough flexibility for implementing the inevitable changes is vital.

    I keep the database model in the back of my mind as I design my games, usually making brief notes. Once the design of the game is complete enough to warrant some trial code, I flesh out and make any modifications to the database design that are needed.

    Once the database design is documented it can be created and work can start on the game code (having a table and column reference to hand whilst coding is an absolute must).

    Considering the additional workload that must be undertaken to rewrite code should you have to change the design of your database, getting the database as close to perfect before you start is essential.

    As such, on large projects not only will I design the database structure, but I will also plan the game using data flow and related diagrams. This lets me check (on paper) that the database structure works before I commit a single line of code. It also breaks the code down into nice manageable units or functions, making the coding process smoother.

  2. I spend large portions of time on getting a database design as flexible and scalable as possible, without knowing all that lies ahead.
    The database is the core of the whole application as Xalthorn pointed out so I go round and round with it until I have a clean enough solution for my needs.
    Granted, changes will need to be made but if the design is flexible enough these changes don't have to cause you to start all over. 🙂

  3. it's reassuring that I'm not the only one that spends a good portion of time designing and planning out my databases. ^^

    Luckily my boss studied databases as his major in comp sci so he's been guiding me on how to properly build and manage them/

  4. Sometimes of course, especially if I'm prototyping something, I'll just throw a quick set of tables together just to test a concept.

    In fact, the alpha test of my current project doesn't even use a database, it stores everything in the session.

    Obviously holding everything in a session is far too daft an idea to maintain for a proper live project, but as the alpha test actually wants people to modify the variables and settings to find the right balance in the system, accelerate to certain 'levels' and so on, it does the job nicely.

  5. I have only one major project, and I started that when I first started coding, so my database design was far from ideal, as you can imagine. And while it's created headaches for me, it's luckily nothing that can't be fixed. Just takes a fair amount of recoding and then copying stuff from one DB to the next. So while planning ahead is clearly important to save yourself work down the road, it's not absolutely necessary. I know that for me, it's hard for me to conceptualize exactly what I need in the DB until I start coding, so I generally create more work down the road but at least I get started.

    If that makes sense (it was kind of stream of conscious).

    Off topic: Xalthorn, could you make it so I don't have to be a member of WordPress to comment on your blog (like this blog is)? I was looking at it the other day, and I have some questions for you, but I can't comment because I need to have an account.

  6. I know where you're coming from on the conceptualising. Been there, done that, still do it 😉

    I'll open up the blog for comments. I assumed (possibly incorrectly) that the settings would protect me from random spammers.

  7. Since everything else has been covered one suggestion….

    Have a way to generate the entire database from your design/documentation. It makes life easier and encourages you to make revisions to both rather than say 'f it I'll revise the documentation tomorrow' and forget. =)

  8. LOL

    Actually if you work in SQL, it's a simple enough task to design your tables in a text format that can be used to create your tables, dropping them beforehand if needed. Just write them as a CREATE statement.

    It would also 'force' you to think properly about the database structure in your design.

  9. I'm happy for you that you can remember all the joins, etc. without an organized and visual design.

    I need my pointy arrows and boxes with rough constraints, keys, etc. written in them.

  10. Sometimes I doodle diagrams, but generally I just create a text file with the table names, the fields, data types, where the primary and foreign keys are, and flag any indexes that are needed.

    This text can easily be included into comments at the top of appropriate source code files for easy reference.

    It's probably because I keep designing the same type of databases, and the same structure keeps popping up.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.