问题
I know this might sound a bit ridiculous, but I got a doubt that if we can represent relationship between two tables, how the two table's data is related, is there a way to represent relationship like, each registered user has a seperate pagelikes table. To make it more clear about my doubt, let me explain in this way, students enrolling for a few courses, say c, c++, java or others. Then, we can say:
Student -(enrols for)- courses
which means that student x can register for courses like c, c++, java or courses can be enrolled by 1 or more students.
In the same way, can we, some how, represent the relationship like registered user 1 has a pagelikes_1 table created for him or her?
sample pics: user profile
pagelikes of that user]1
回答1:
TL;DR
Your question is more or less the canonical situation in which one must decide between DDL (Data Definition Language) vs EAV (Entity-Attribute-Value).
Use one table if you can
Normally, you would have one table which is the union of all the tables you are talking about. As for enrolments.
// student [student] is enrolled in [course]
Enrolment(student,course)
PK (student, course)
FK (student) to Student (student)
FK (course) to Course (course)
// user [user] likes page [page]
Likes(user,page)
PK (user, page)
FK (user) to User (user)
There isn't a standard ER way to indicate a table per entity instance, ie an association set per entity instance. That's because you would normally have one liked page table, as for enrolments.
Constrain the user table and tables about tables
There are "metadata" tables that describe the database itself. (Details depend on the DBMS.) There will be a table that I'll call Table with a column that I'll call tablename with a row for each database table, holding its name in tablename. The "relationship", ie constraint, that you want can be expressed between Table and a User table. (But not necessarily declaratively in a particular SQL DBMS.)
It's not clear exactly what relationship/constraint you want to record. Probably you want to say at least that if a table with a name like Likes_user exists then its user does. That is not a "relationship"/constraint of the kind that ER diagrams display, which are FKs (foreign keys). That cannot be expressed declaratively by most (but not all) SQL DBMSs. It is NOT EXISTS(select tablename from Table where tablename like 'Likes_%' except select CONCAT('Likes_', user) as tablename from User).
You could calculate and store a user's tablename in a User column likestablename and declare a FK Table (tablename) references User (likestablename). (Declare likestablename as a computed column, if your DBMS allows it.) If you could add a nullable user column to Table then you could declare 'FK Table (user) references User (user). But you can't because it's a system table. You could declare a view but SQL won't let you declare FKs in views.
You may also want every User user to have a tablename in Table tablename. That is
NOT EXISTS(select CONCAT('Likes_', user) as tablename from User except select tablename from Table where tablename like 'Likes_%').
If Table tablename values were just like the User user values then you could instead declare a FK User (user) references Table (tablename). Since they differ, you can use the User tablename technique to just declare a FK User (tablename) references Table (tablename).
If you want both of these constraints then you want every user to have an exactly-1-to-exactly-1 (ie "1-to-1 correspondence") between some rows of two tables tables. That is not easy to do declaratively in most SQL DBMSs even for all rows because they won't allow FKs in both directions between tables. Normally you could handle the all-rows case by pairing them up in the same table. (Possibly involving views.) But here you can't because Table is a system table.
If your Likes_user tables have different columns then it's DDL vs EAV
You might want different columns in each of the tables. Then indeed you could have multiple Likes_user tables managed by DML and DDL, which is clear and uses the DBMS fully. But if in this different-columns case after testing and costing the DDL is inadequate you could use a single table along with multiple tables and/or null columns. These implement a technique "EAV" that is otherwise an anti-pattern since you lose a lot of DBMS functionality.
来源：https://stackoverflow.com/questions/33551181/is-there-a-way-to-represent-relationship-between-a-tuple-and-to-a-table-in-e-r-d