Re: Clues on modeling a really simple concept
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 07 Apr 2009 23:27:54 -0300
Message-ID: <49dc0baf$0$5470$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.
Date: Tue, 07 Apr 2009 23:27:54 -0300
Message-ID: <49dc0baf$0$5470$9a566e8b_at_news.aliant.net>
Spike wrote:
> On 7 abr, 02:43, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>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 think (and hope) i have not expressed myself correctly. > > Im modeling this software for fun. It is a private project. No > requirements to relax and no security issues because it is just a > draft, an idea. > > I just wanted some clues on this kind of things. As simple as "This is > what i would do: ...".
What I would do is learn the fundamentals first.
> It turns out that this has become something like an aggressive > modeling lesson, that i may or may not need (im a software engineer, > btw), and simply thats not the point.
Then you have no excuse. Presumably as an engineer you understand the importance of applying science and mathematics. Presumably as a software engineer in particular you have the intelligence and education to understand sets, relations, predicate logic etc.
An assertion about a photograph in a gallery is different from a similar statement about the gallery itself.
> Provided this wold had been a "real life" project, i would be cautious > and respect normal models based on what someone asks for as i use to.
I can extract nothing meaningful from the above sentence.
<snip> Received on Wed Apr 08 2009 - 04:27:54 CEST