I know that this is the standard means of dealing with a many to many
relationship, I'm just not sure it fits here.
> USER:
> emailID (PK)
> userName
> Password
> Address
> Etc
>
> FRIEND:
> emailID (PK)
>
> USER_FRIEND
> user_emailID (PK)
> friend_emailID (PK)
So if I want a list of USER [EMAIL PROTECTED]'s friends:
SELECT friend_emailID from USER_FRIEND
WHERE user_emailID="[EMAIL PROTECTED]"
In this (and pretty much every case), the FRIEND table is useless and
doesn't make sense logically.
*I THINK I EXPLAINED THINGS INCORRECTLY*
Let me try again:
* I'm not sure if it's even a true many to many relationship as this is
actually a relationship between ONE RECORD in a TABLE and a ANOTHER RECORD
in THE SAME TABLE!
A USER is:
USER
emailID
userName
A friend is really just another RECORD in the USER table.
i.e. IF I HAD TO MAP THE RELATIONSHIP LOGICALLY, IT WOULD BE:
USER:
emailID
userName
| 1
| many
FRIEND:
emailID
| many
| 1
USER:
emailID
username
(i.e. it's two records in the same USER table)
How are relationships between records in the same table usually dealt with
in terms of design? Implementation?
ThanX,
Ben
""Jim Lyons"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Indexes speed up joins. Foreign keys should be indexes themselves, so
> they
> can also speed up joins. If the FK is not an index, it won't help. So,
> index your FKs
>
> On Wed, Oct 8, 2008 at 10:43 AM, Ben A.H. <[EMAIL PROTECTED]> wrote:
>
>> Does using foreign keys simply enforce referential integrity OR can it
>> also
>> speed up JOIN queries?
>>
>>
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/[EMAIL PROTECTED]
>>
>>
>
>
> --
> Jim Lyons
> Web developer / Database administrator
> http://www.weblyons.com
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
