Skip to Main Content
  • Questions
  • date field in many to many relationships

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, harsha.

Asked: April 10, 2008 - 10:13 am UTC

Last updated: April 11, 2008 - 8:46 am UTC

Version: 9.0.2

Viewed 1000+ times

You Asked

Hi Tom,
Good morning. While resolving many-many relationships, we create an intersection table and we create a FK for the other two table Primary keys. But if the PK tables have date fields in them i.e. hire date,create date etc, do we need to keep them in the intersection table? Could you please let me know what are the columns other than the PK columns we need to keep in the intersection table. If possible could you please provide some examples to understand them?
Thank you so much for your time

and Tom said...

you simply take the primary keys from the two tables and put them into the intersection table.

so, if your primary key included a date field (an excessively bad practice, to be frowned upon) - then yes, of course your intersection table would have them

If your primary key does not include this - then no, you would not copy any data down from the parent tables into this intersection table.

Rating

  (4 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

harsha pendyala, April 10, 2008 - 12:50 pm UTC

Thank you so much Tom for taking time to answer my question. It really helped me to understand how to manage many-many relationships.

David Aldridge, April 10, 2008 - 2:01 pm UTC

"if your primary key included a date field (an excessively bad practice, to be frowned upon) "

What an intriguing comment ... :)
Tom Kyte
April 10, 2008 - 2:54 pm UTC

the only time I think it would be "ok" would be in a dimension table in a warehouse star schema.

In a transactional system, I cannot imagine including the timestamp as part of the key.

Intersection qualities

Michael O'Shaughnessy, April 10, 2008 - 8:17 pm UTC

Of course it should be noted that the intersection table could have new intersect-dependent columns in addition to the compound primary key. For instance, two tables: STUDENT and COURSE where the STUDENT_COURSE table has an CLASSROOM column, CLASSROOM being dependent upon neither STUDENT nor course but the intersection of the two.
Tom Kyte
April 10, 2008 - 8:35 pm UTC

absolutely, association objects may have their own attributes - definitely.

Rajinder, April 11, 2008 - 8:14 am UTC

Tom,
A related question (and my apologies if it seems a bit divergent.) In the example quoted above, the two "base" tables have a primary key each which become foreign keys in the intersection table. The base table is indexed on PK's and the intesection table has a in-line constraints specifying foreign keys as primary keys in the intersection table. Do I need to index these FKs or is Oracle smart enough to use the index created in the base tables?
Thanks for your response.
Tom Kyte
April 11, 2008 - 8:46 am UTC

how would an index on the base tables help in accessing rows in the intersection table.

typically, you query something like (using students and courses and an intersection of student_to_courses)

select *
  from students s, students_to_courses sc, courses c
 where s.student_name = 'TKYTE'
   and s.student_id = sc.student_id
   and sc.course_id = c.course_id;


Now, we would hope for an index on student_name - to find the row(s) in S fast.

We now have a set of student_ids for TKYTE.

We need to now access students_to_course to find the set of course_ids, we do that by student_id

Hence, we need an index on student_id in the SC table. We probably have that since student_id,course_id is the primary key - we have the primary key index.

However, we also frequently query the other direction:

select *
  from students s, students_to_courses sc, courses c
 where c.course_name = 'Intro to DBA'
   and s.student_id = sc.student_id
   and sc.course_id = c.course_id;



Here we start at course, goto SC by course_id - we need an index on course_id in SC therefore. We have an index on (student_id,course_id), but nothing that starts on course_id - so, we'd need to index that column - yes - in general