Re: Clues on modeling a really simple concept
Date: Mon, 06 Apr 2009 21:43:15 -0300
Message-ID: <49daa1a7$0$5463$9a566e8b_at_news.aliant.net>
Spike wrote:
> On 7 abr, 01:38, jefftyzzer <jefftyz..._at_sbcglobal.net> wrote:
>
>>On Apr 6, 3:40 pm, Spike <fau..._at_gmail.com> wrote:
>>
>>>On 6 abr, 23:11, Bernard Peek <b..._at_shrdlu.com> wrote:
>>
>>>>In message
>>>><16d72645-6a6b-4fd4-bccf-d5002970f..._at_q2g2000vbr.googlegroups.com>,
>>>>Spike <fau..._at_gmail.com> writes
>>
>>>>>My question is: Should i add a relationship between galleries and
>>>>>users?
>>
>>>>>I would like to query which galleries a user has, and i don't really
>>>>>know if it is worth adding a foreign key rather than doing a three-
>>>>>level join query each time i want to obtain this data.
>>
>>>>Less is more. The database is fully normalised without adding an extra
>>>>relationship. You shouldn't denormalise without a good reason.
>>>>Denormalised systems are usually more fragile and will cost you more
>>>>time in programming and maintenance.
>>
>>>>Of course if there is some other real-world relationship between
>>>>galleries and users you may need to change the model. Do galleries have
>>>>Owners, for instance and would those be Users?
>>
>>>>--
>>>>Bernard Peek
>>
>>>Hi!
>>
>>>I was thinking about system performance vs. normalization. By adding
>>>that extra relationship, three-level joins can be avoided, and so
>>>stressing the dbms too much.
>>
>>>Do you think is a good idea in general to denormalize the data model
>>>by means of performance?
>>
>>>Thanks!
>>
>>Spike,
>>
>>I'm not sure if you're deliberately trying to be provocative, but I'd
>>say it's fair to characterize this newsgroup as denormalization-
>>hostile ;-).
> > Its the very first time i post (and even read) this newsgroup, so no, > im not deliberately provocative. >
>>What's more important, I think, is to put first things first, and as I
>>hinted at--and others made explicit--what's paramount is getting the
>>requirements right and accurately modeling the problem domain. If
>>users create galleries, and/or galleries can exist independently of
>>any pictures being assigned to them, then model accordingly. Period.
>>
>>Bottom-line, IMHO: 1) model the domain accurately, and 2) deviate from
>>the model only when *truly* warranted (NB that often denormalization
>>is zero-sum--who cares when the data comes back faster when it's wrong
>>or contradictory?). You might want to see if you can find a copy of
>>"The Normal Is So... Interesting" by Chris Date (DBP&D 11/97) for more
>>on the topic of denormalization. Many other sources abound.
> > The problem here is that users should be able to upload pictures > without specifying a particular gallery (i will use a default one). > In a similar way, the should be able to create an empty gallery. > > Thus, there are two options: make a relationship between users and > galleries or create a record in the join table between pictures and > galleries with null values on foreign keys.
The latter is wrong. Wrong in so many ways and on so many levels, it would be tedious to try to enumerate them.
If a user can create and own empty galleries, then, obviously, gallery has some direct join path to user. Failure to capture that would lead to stupid errors like the inclusion of another person's picture in one's gallery suddenly conferring ownership of the gallery to the other person. That, in itself, is an obvious potential security flaw.
I strongly recommend you learn at least some of the fundamentals before you start designing anything that might impact the public.
> I dont really like any of the two options, but if one of them > increases overall performance, that will be a good decision maker.
Like and dislike has nothing to do with acting like a professional. While performance is an important consideration, fast and incorrect is no better than slow and incorrect; it is simply incorrect.
A responsible and competent designer starts with correct and works from there to achieve the required performance characteristics. Only an ignorant boob would design for performance without any consideration for the actual requirements. Received on Tue Apr 07 2009 - 02:43:15 CEST