Re: Designing DB in accordance with the relational model

From: Kentauros <joker.vd_at_gmail.com>
Date: Sat, 13 Nov 2010 07:18:48 -0800 (PST)
Message-ID: <2c78f93e-29fb-4212-8de6-d382259d38b6_at_y37g2000vbl.googlegroups.com>



On Nov 13, 2:49 am, Hugo Kornelis
<h..._at_perFact.REMOVETHIS.info.INVALID> wrote:

> Don't forget that in the context of databases, "redundancy" refers to
> representing the same *fact* more than once, not about storing the
> same *value* more than once.
>
> [...] As long as you stick to your choice. You should not try to
> combine these alternatives - as that WOULD introduce the
> redundancy you already thought to see in the first alternative.

Oh. That makes sense. Thank you!

> Unless it is possible for a character to exist in a game with no
> characteristic at all (and you have already told us it isn't), the
> existence of a character in a game is implied by the character having
> characteristics in that game; adding a seperate relvar to store its
> existence would be redundant.

Ooops. Indeed. Thanks again.

> Most people in the field will tell you that it is not good practice to
> have constraints that need to change based on foreseeable changes in
> the world.
> They'll also tell you that is is best not to mix data and metadata.
>
> Your constraint violates both advices.

Well... I don't think I agree, but maybe it is just because I have to little experience in this field. I'll think about this.

> >> I'm also wondering about your choice to use seperate tables for each
> >> characteristic (attack, defense, special, ...). Not that this is
> >> really WRONG, but it might not be the best choice either. Have you
> >> considered the predicate "<Character> has <Characteristic> <score> in
> >> <Game>" to replace all these?
> >Yes. And I don't think it will work. What will the domain of <score>
> >be? Alpha? No, thank you very much. Such relation would require an
> >enormous number of constraints.
>
> Yes, that is true. Welcome rock, meet hard place. You'll either have a
> model that's easy to query and has lots of nasty constraints, or you
> can choose a model with relatively simple constraint that is tough to
> query. Neither of these choices is automatically better than the
> other; it's a choice you'll have to make, based on how you expect the
> system to be used.

Well. Actually, when I query some data about character, I specify what I want to get, so if I get (after projecting JOINS) an empty relation, well, that just means I requested for non-existing data on this character in this game. Or that the character itself doesn't exist... either way, it is easy to notice and easy to find out why it happened :-)
And again, I can use views to group data by games. Received on Sat Nov 13 2010 - 09:18:48 CST

Original text of this message