such as topic, such as the system has the following table:
1, the student table
2, students and contact associative table
3, contact table
4, the student and the class association list
5, class table
6, classes and courses associative table
7, the curriculum
,,,

we regardless of the associative table is in line with the practical significance, the relationship is reasonable, and whether a one-to-many or many-to-many, anyway, is there are a lot of correlation,

So:
table 2: students and contact associative table , there should be three fields:
Field 1: the correlation ID
Field 2: student ID
Field 3: contact ID

table 4: the student and the class association list , in the same way:
Field 1: the correlation ID
Field 2: student ID
ID field 3: class

table 6: classes and courses associative table , in the same way:
Field 1: the correlation ID
ID field 2: class
Field 3: the course ID
,,,

if a lot of this kind of relationship in the system, each relationship to create a the table, in the end may be have a lot of associative table,

I think the associative table can be pulled out, forming a public relation table, what kind of data is maintained by a type field, relationship through the code and documentation control,

The result is similar to:

public association list:
Field 1: the correlation ID
Field 2: source ID
Field 3: the target ID
Type field 4:
Field 5: note
,,,

public relation table type specification table (optional, similar documents) :
Field 1: ID
Type field 2:
Field 3: ((source ID and the relationship between the target ID)
,,,

if pulled into this structure, all relationship will go this table, to maintain a little bit better, can also provide a unified API to deal with the associative table data,

But this approach also has the place with bad, is if the relationship is very complicated, forgot to write related instructions, will be more easy to mess, is not easy to expand, more data will affect the efficiency, etc.,

Want to consult everybody, how to see two ways this? If you choose, how will choose?

CodePudding user response:

Relationship doesn't work, sometimes more than one, use your example extension, plus a term dimension you want to do? Each student every semester in different classes, different classes, the limitations of the public relation table is too big, in the actual business is likely to be more trouble,

General can write one-on-one are put one table, not put it with associative table, don't think so complicated,