Re: Clues on modeling a really simple concept

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 6 Apr 2009 20:58:17 -0400
Message-ID: <JyxCl.15737$W06.13552_at_flpi148.ffdc.sbc.com>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news: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.

I have to agree with Bob on this point. Received on Tue Apr 07 2009 - 02:58:17 CEST

Original text of this message