Which database structure to choose? [closed]

问题

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 7 years ago.

I want to implement a notification system. I have users and each user has notification setting

Structure 1:

 Users                Notification_settings                Notifications
 -id (pk)             -id                                   -id (pk)
 -username            -user_id (fk) references Users        -user_id (fk)
 -password            -receive_email (boolean)              -message
                                                            -is_read

Structure 2:

 Users                                               Notifications_settings
 -id (pk)                                             -id (pk) 
 -setting_id (fk) references Notifications_settings   -receive_email
 -username                                            
 -password            

 Notifications
 -id (pk)
 -user_id (fk)
 -message
 -is_read

Which database structure to choose or any other database structure for notification system ?

回答1:

And now for a Joe Celko quote:

A strong entity is one that exists on its own merit. A weak entity is one that exists because of a strong entity. The classic example is that of a sales order; the order header is strong and the order details are weak. If the order is dropped, then all the order details should disappear.

So, then, can a User exist on it's own without a Notification? Then the Notifications table should have the foreign key to Users. Is the converse true? Then make it the other way. Are neither of these true? Then perhaps your model is incorrect, and there should be a junction table between them (even with unique constraints on it), or maybe they truly do belong in the same table. I don't particularly like this last option of putting them in the same table because you've already naturally come up with two nouns to describe distinct entities.

Can other entities other than Users "have a" Notification? Maybe this kind of thinking could help you model this domain.

Update - Some additional ideas:

If you were to put all of these columns into one table, which of them, if any, now looks like it's going to contain redundant data? Let's imagine there are only a few different messages now. Perhaps you don't need a Notifications table but a Messages table, and a junction table between that and Users which could store Messages sent to Users over time, including if they've been read or not. The receive_email could be a better attribute of Users at this point, though maybe just having a Message mapped to a User is enough to say that this User should receive email. These are just some of the things that I might be thinking and would hope to lead to a better understanding of the app.

Also, beware that the bit/boolean datatype is not ANSI SQL, can often be derived from other data, or can even turn into an int down the road mapping to multiple statuses.

回答2:

It seems like it should be users < notifications (one to many), but maybe you have a specific reason that it should be 1-1. In that case, I would make the parent table (the one without the FK column) the table with more one-to-many relationships. So, naturally, it would make sense to use store the user ID in the notification table.

It would seem that a notification would always have a user, but NOT vice-versa. Therefore, you should store the foreign key to a UserID in your notification table -- and not the other way around.

edit-- as others have suggested, if you truly do want a 1-1 relationship, you could just add notification fields to the User table. These seems to violate normalization rules at a glance, but if it reeeaaaally is a 1-1 relationship, then by all means, have at it

Edit 2- Since you explicitly stated that a notification does not exist without a user, I will definitively say that you should store the foreign key to a User in the Notifications table, no exceptions (except if you want to store notification information inside the user's table :)

Edit #2937:

You should store the user's notification preferences in the User table - there's no need to split that into a different table unless you have some obfuscated design and have 256 columns for your user already and that is the limit.

You should store the notifications in a separate table, with a One-Many Relationship from Users to Notifications. That is my final answe, Regis :)

回答3:

If your site is not huge in traffic, u put it all in the same table (user and settings). This is the relevant answer for the OP.
Usually, u separate 1:1 into different tables when several conditions happen (together):

1. each group of fields is relevant to a different module in your app
2. each group of fields is access in different rates (username/password each login, billing settings once/twice in a week, for example)
3. There is huge traffic into your site, where u need to milk any ounch of performance from your system

As u can see from above, most do not need to separate it.

来源：https://stackoverflow.com/questions/14698980/which-database-structure-to-choose