views:

93

answers:

3

Sorry for the title, it's difficult to explain.

I need a data model similar to this: alt text

As you can see, a set can belong to both a user or a school. My problem: It should only be allowed to belong either to a user OR a school. But never both at the same time.

How can I solve this problem?

+1  A: 

You'll have to use a trigger to enforce this business rule, because MySQL has but don't enforce CHECK constraints (on any engine).

OMG Ponies
+2  A: 

With the caveat: It's not entirely clear what a Set is in your data model.

I'm questioning your data model.

Why do User -> Sets and School -> Sets have to point to the same table. It's not more Normalized if those are really independent sets of data. Just because they share some similarities in the columns that they track doesn't mean they should be stored in the same table. Are they logically the same thing?

Just create separate tables for School Sets and for User Sets. This will make inverse queries easier as well because you won't have to check for null relationships in the Sets table to know if it's really a UserSet or a SchoolSet.

geofflane
Thanks for the hint. Actually the sets (many vocabs make a set) are exactly the same, they can just have different owners, either a school or a user.As a set will never be moved from belonging to a school to belonging to a user or vice versa, I could simply create two types of sets and copy the data to the other table when necessary. The problem with this approach is, that then I'll need two types of vocabs, and I don't really think that would make a lot of sense.
danilo
You could probably put a SetOwner table in between Users/Schools and Sets. Then each of the tables that could 'own' a Set would have a FK column to a set_owner_id. The Set table then would have a set_owner_id as well. So basically a User and a School have a 1:1 relationship to SetOwner and SetOwner is 1:m to Set.Then everything has enforceable referential integrity. That will make it quite hard to go from Set to Owner (logical) though.
geofflane
You mean like this? http://i.imgur.com/dVRs9.pngI don't really understand though how this solves the problem.
danilo
Yeah, like that. It ensures there is only one SetOwner for a given User or School. It also ensures that a Set can only belong to a single SetOwner (which means either a School OR a User, but not both). That will work if you generally navigate from School or User to the Sets.
geofflane
+2  A: 

Your current design is called exclusive arcs where the sets table has two foreign keys, and needs exactly one of them to be non-null. This is one way to implement polymorphic associations, since a given foreign key can reference only one target table.

Another solution is to make a common "supertable" that both users and schools references, and then use that as the parent of sets.

create table set_owner

create table users 
  PK is also FK --> set_owner

create table schools
  PK is also FK --> set_owner

create table sets 
  FK --> set_owner

You can think of this as analogous to an interface in OO modeling:

interface SetOwner { ... }

class User implements SetOwner { ... }

class School implements SetOwner { ... }

class Set {
  SetOwner owner;
}

Re your comments:

So the SetOwner table contains both UserIDs and SchoolIDs, correct? That would mean that I wouldn't be allowed to have the same ID for an user and a school. How can I enforce this?

Let the SetOwners table generate id values. You have to insert into SetOwners before you can insert into either Users or Schools. So make the id's in Users and Schools not auto-incrementing; just use the value that was generated by SetOwners:

INSERT INTO SetOwners DEFAULT VALUES; -- generates an id
INSERT INTO Schools (id, name, location) VALUES (LAST_INSERT_ID(), 'name', 'location');

This way no given id value will be used for both a school and a user.

If I'd like to get the owner type for a set, do I need an ownerType attribute in my SetOwner table?

You can certainly do this. In fact, there may be other columns that are common to both Users and Schools, and you could put these columns in the supertable SetOwners. This gets into Martin Fowler's Class Table Inheritance pattern.

And if I want to get the name of the school or the user (whichever type it is), can I do this with a single query, or do I need two queries (first to get the type and second to get the name)?

You need to do a join. If you're querying from a given Set and you know it belongs to a user (not a school) you can skip joining to SetOwners and join directly to Users. Joins don't necessarily have to go by foreign keys.

SELECT u.name FROM Sets s JOIN Users u ON s.SetOwner_id = u.id WHERE ...

If you don't know whether a given set belongs to a User or a School, you'd have to do an outer join to both:

SELECT COALESCE(u.name, sc.name) AS name 
FROM Sets s 
LEFT OUTER JOIN Users u ON s.SetOwner_id = u.id
LEFT OUTER JOIN Schools sc ON s.SetOwner_id = sc.id 
WHERE ...

You know that the SetOwner_id must match one or the other table, Users or Schools, but not both.

Bill Karwin
Thanks for the great explanation. The approach with the supertable seems similar to the one that geofflane proposed in his comment.I think I understand the concept now. So the `SetOwner` table contains both UserIDs and SchoolIDs, correct? That would mean that I wouldn't be allowed to have the same ID for an user and a school. How can I enforce this?
danilo
And another aspect: The ERD currently looks like this http://imgur.com/vD1ln.png. If I'd like to get the owner type for a set, do I need an ownerType attribute in my SetOwner table? Or is there another way to do it? And if I want to get the name of the school or the user (whichever type it is), can I do this with a single query, or do I need two queries (first to get the type and second to get the name)?
danilo
Awesome edit, thank you. That's why I love Stackoverflow.There's only one remaining question: Can I safely use `LAST_INSERT_ID()` in a multiuser environment, or can queries and inserts by other users interfere with the current query, so that the LAST_INSERT_ID changes?
danilo
Sorry for the quadruple comment: I found the answer myself. "The ID that was generated is maintained in the server on a per-connection basis." http://dev.mysql.com/doc/refman/5.1/en/information-functions.html#function_last-insert-id
danilo
Yes, that function wouldn't provide any benefit if it were susceptible to race conditions. All databases provide a way to get the last generated pseudokey value in your current connection, even if other clients are also generating pseudokey values.
Bill Karwin