与一个表的几个多对多关系

Question

My database has several categories to which I want to attach user-authored text "notes". For instance, an entry in a high level table named jobs may have several notes written by the user about it, but so might a lower level entry in sub_projects . Since these notes would all be of the same format, I'm wondering if I could simplify things by having only one notes table rather than a series of tables like job_notes or project_notes , and then use multiple many-to-many relationships to link it to several other tables at once.

If this isn't a deeply flawed idea from the get go (let me know if it is!), I'm wondering what the best way to do this might be. As I see it, I could do it in two ways:

1. Have a many-to-many junction table for each larger category, like job_notes_mapping and project_notes_mapping , and manage the MtM relationships individually

2. Have a single junction table linked to either an enum or separate table for table_type , which specifies what table the MtM relationship is mapping to:

    +-------------+-------------+---------------+ | note_id | table_id | table_type_id | +-------------+-------------+---------------+ | 1 | 1 | jobs | | 2 | 2 | jobs | | 3 | 1 | project | | 4 | 2 | subproject | | ........... | ........... | ........ | +-------------+-------------+---------------+ 

Forgive me if any of these are completely horrible ideas, but I thought it might be an interesting question at least conceptually.

Answer 1

The ideal way, IMO, would be to have a supertype of jobs, projects and subprojects - let's call it activities - on which you could define any common fact types.

For example (I'm assuming jobs, projects and subprojects form a containment hierarchy):

activities (activity PK, activity_name, begin_date, ...)
jobs (job_activity PK/FK, ...)
projects (project_activity PK/FK, job_activity FK, ...)
subprojects (subproject_activity PK/FK, project_activity FK, ...)

Unfortunately, most database schemas define unique auto-incrementing identifiers PER TABLE which makes it very difficult to implement supertyping after data has been loaded. PostgreSQL allows sequences to be reused, which is great, some other DBMSs (like MySQL) don't make it easy at all.

My second choice would be your option 1, since it allows foreign key constraints to be defined. I don't like option 2 at all.

Answer 2

Unfortunately, we have ended up going with the ugliest answer to this, which is to have a notes table for every different type of entry - job_notes, project_notes, and subproject_notes. Our reasons for this were as follows:

• A single junction table with a column containing the "type" of junction has poor performance since none of the foreign keys are "real" and must be manually searched. This is compounded by the fact that the Notes field contains a lot of text per entry.

• A junction table per entry adds an additional table over simply having separate notes tables for every table type, and while it seems slightly prettier, it does not create substantial performance gains.

I'm not satisfied with this answer, because it seems so wasteful to effectively be duplicating the same Notes table for every job/project/subproject table that is being described. However, we haven't been able to come up with an answer that would hold up performance wise in the long term. I'll leave this open in case anyone has better recommendations for how to do this!