QuackFuzed [ Ramblings of a Con..ColdFuzed Mind ]

RSS

QuackFuzed.com is the personal ColdFusion coding blog of Matt Quackenbush. It exists primarily as a place for the author to learn, and hopefully to assist others in learning and/or avoiding some of the same pitfalls and mistakes. (Quack certainly makes enough mistakes daily to make up for the entire ColdFusion community.)

Transfer: Many-to-One or One-to-One?

Posted on November 9, 2008 at 2:20 PM in ColdFusion, Transfer

This post is actually a response to a post by Ray Camden. I planned to add a comment to Ray's blog, but I felt it was too long to be considered merely a comment. Here's a snippet from Ray's post that I am specifically responding to:

[Continue Reading]

Comments (10) | Send | del.icio.us | Digg It! | Linking Blogs | 7197 Views
Comments
(Comment Moderation is enabled. Your comment will not appear until approved.)

On 11/9/08 at 4:19 PM, Justin Carter said:

Yeah, in this case it's definitely a Many-to-One relationship, many Employees belong to one Department. If you were to enforce referential integrity at the key level as a One-to-One relationship the database would complain as soon as you tried to assign a second Employee to a Department that already had an Employee assigned to it.

On 11/9/08 at 11:52 PM, Raymond Camden said:

My problem with your argument is that it is logical. ;) I'm not saying that ManyToOne is wrong - I'm just saying it isn't how my brain works. :) You said, "Think about your database tables for a moment...", but isn't the point of an ORM to stop thinking about the database and start thinking of the model?

Also, I get that there are many emps to one department. However, when I'm defining the emp object, I look at it as defining _A_ employee. To me, _A_ employee maps to _A_ department.

On 11/10/08 at 12:17 AM, Matt Quackenbush said:

@ Ray- Okay, so ignore the database. It's completely irrelevant. Let's look at it from the model's perspective. We are talking about a relationship between two entities: Employee, and Department.

A relationship is a two-way thing. So you *have* to look at it from both angles.

(A) Employee Object: How many Departments am I permitted to have? One? Many?

(B) Department Object: How many Employees am I permitted to have? One? Many?

The answer to (A) is still One, and the answer to (B) is still Many. No matter how you slice the pie, Employee > Department is a Many-to-One relationship.

On 11/10/08 at 12:22 AM, Raymond Camden said:

That makes sense. I'm not saying it doesn't. I'm just saying my brain is 'sticking' on it. ;) And it sticks on it every time I work with Transfer. This last comment though is merging nicely into the gray matter, so maybe next time it will be easier. :)

On 11/10/08 at 2:59 AM, John Gag said:

I believe that a one to one relationship is rare in a database design but they do occur. Also, a many to many usually needs a child table and should rarely exist also. My 2 cents

On 11/10/08 at 4:49 AM, duncan said:

John, I frequently have to use many-to-many child tables. Why shouldn't they exist? For instance, suppose you have the situation where one employee can actually belong to two departments? Or lets say you have a table for Products, and another for Colours. Each product comes in many colours; each colour can belong to multiple products. Without denormalising your tables and having a FK column that lists all the options, how do you deal with this without the child table?

On 11/10/08 at 12:02 PM, John Gag said:

@Duncan - Many to many relationships only exist in a denormalized form. In reality you should have a child table between the many to many creating two one to manys. This child table can also be referred to as a junction table or a detail table. I believe this should be done by 3rd normalized form.

On 11/10/08 at 1:40 PM, duncan said:

ah, I misunderstood you, I thought you were saying you shouldn't use the child tables to do the 1-M / M-1 join between the two parent tables.

On 11/10/08 at 1:46 PM, John Gag said:

@Duncan - Yeah, maybe I should have been a little more clear my first post :)

On 11/15/08 at 12:38 PM, Gerald Guido said:

Thanx Matt,
I am just starting to get my head around this and as you know the initial learning curve is often contains the biggest stumbling blocks. The is really helped me get it straight in my head.
[Add Comment]
CodeBassRadio

Latest Articles

Eventually something really brilliant and witty will appear right here.

Categories

Quick Links

Blogs I Read

Calendar

November 2008
S M T W T F S
« Oct   Dec »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            

Subscribe

Enter a valid email address.

The Obligatory Wish List

My Amazon.com Wish List