What is the best practice to encode this relationship in a postgres database schema?
Given the following entities: Document, Profile, Message
And the following relationships:
One Profile to many Documents
One Message to many Documents
Essentially documents are a shared resource used by other entities. Should I use different Join Tables for each related entity? Is there some other way to set this up? It is possible in the future that other entities will reference Documents
For anyone who finds this post and wants an actual answer: The foreign key for the relation HAS to be on the many-to-one side of the relationship or there has to be a join table mapping the relation. You cannot store multiple foreign keys in a single column on the one-to-many side of the relationship.
A one-to-many relationship is modeled with a foreign key, in this case in the documents table. If you need two such relationships, define two foreign keys.
Related
I am using EF 6 Code-First, table per type, and I have two concrete classes Group and User. Group has a navigation property Members which contains a collection of User. I have mapped this many-to-many relationship in EF using Fluent syntax:
modelBuilder.Entity<Group>
.HasMany<User>(g => g.Members)
.WithMany(u => u.Groups);
I would like to be able to say when a member has joined a group so that I can query for, say, the newest member(s). I am not sure of how this is best accomplished within the framework.
I see the following options:
Create and use an audit table (ie GroupMembershipAudit consisting of Group, User, join/unjoin, and DateTime
Add a column to the autogenerated many-to-many table between User and Group
Is there anything within EF to facilitate this sort of storage of many-to-many historical info like this / append columns to the many-to-many relationship?
Add a column to the autogenerated many-to-many table between User and
Group
That is not possible - auto-generated junction tables can contain only keys (that is called Pure Join Table). According to Working with Many-to-Many Data Relationships article: If the join table contains fields that are not keys, the table is not a PJT and therefore Entity Framework cannot create a direct-navigation (many-to-many) association between the tables. (Join tables with non-key fields are also known as join tables with payload.)
Create and use an audit table (ie GroupMembershipAudit consisting of
Group, User, join/unjoin, and DateTime
Actually you should create GroupMembershipAudit entity. With Code First table will be generated, you don't need to create it manually.
I am a beginner to using JPA 2.0 and databases in general and I was just confused about a few concepts.
So I have a total of 3 tables. One is the UserTable, which contains all the information about my user. It has a primary key field called user_Id. My other two tables are ExercisesTable and FoodIntakeTable, and they each have a foreign key field called user_Id to reference the user_Id in my UserTable. I want a one-to-many relationship from my user_Id table to each of the two tables so I can find pull out exercise information or food information for a user.
Pretty much like this:
FoodIntakeTable <-> UserTable <-> ExercisesTable
I need a bidirectional mapping from UserTable to FoodIntakeTable and also a bidirectional mapping from UserTable to ExercisesTable from the field user_Id.
The problem is, when I try to write my code like this in my Usertable class:
#OneToMany(mappedBy="ExercisesTable.userId")
#OneToMany(mappedBy="FoodIntakeTable.userId")
public long userId;
It's illegal because I can't have two #OneToMany annotations on the same field. I think it's supposed to be legal in a normal relational database and I'm just confused about how you translate this into JPA. I'm very new to the whole concept of databases and entities in general, so any help would be appreciated.
In JPA you can directly reference entity objects instead of the ids that they are mapped by. Try something like this:
You should have an entity type for each of your tables, say Exercise for ExercisesTable, FoodIntake for FoodIntakeTable, and User for your UserTable.
Then your User entity is the owning side of the relationships, having one field per relationship like this:
#OneToMany(mappedBy=...)
private List<Exercise> exercises;
#OneToMany(mappedBy=...)
private List<FoodIntake> foodIntakes;
I've got a table "Persons" (PersonId, Name, Address) which contains information about people. I then subclass this information with tables "Clients" (PersonId, DateJoined) and Victims (PersonId, DateAssassinated).
In SSMS I have established an FK relationship FK_Clients_Persons and FK_Victims_Persons where the Primary Key is Persons.PersonId and the foreign key is the eponymous field in the Clients and Victims tables respectively. In SSMS I cannot see any obvious functional difference between these relationships.
However, in ADO.NET Entities when I create the model from the database, the tool does not identify FK_Victims_Persons but it does recognise FK_Clients_Persons. It just treats Victims.PersonId as a simple field and doesn't generate relationship members for it. The missing FK relationship does not appear in the Constraints tree of the Model Browser, but the other one does.
I have no idea why this is, has anyone faced this problem before?
No matter how many times I start over, I can't get it to work.
I have my app using core data with the data model below. However, I'm switching to a standard database with columns and rows. Can anyone help me with setting up this new database schema?
First of all you need to create tables for each of the Entities and their attributes (note I added "id" to each of the tables for relationships):
Routine (name, timestamp, id)
Exercise - this looks like a duplicate to me, so leaving one only here (muscleGroup, musclePicture, name, timeStamp, id)
Session (timeStamp, id)
Set (reps, timeStamp, unit, weight, id)
Now that you have tables that describe each of the entities, you need to create tables that will describe the relationships between these entities - as before table names are in capitals and their fields are in parenthesis:
RoutineExercises (routine_id, exercise_id)
SessionExercises (session_id, exercise_id)
ExerciseSets (exercise_id, set_id)
That's it! Now if you need to add an exercise to a routine, you simply:
Add an entry into Exercise table
Establish the relationship by adding a tuple into RoutineExercises table where routine_id is your routine ID and exercise_id is the ID of the newly created entry in the Exercise table
This will hold true for all the rest of the relationships.
NOTE: Your core data model has one-to-many and many-to-many relationships. If you want to specifically enforce that a relationship is one-to-many (e.g. Exercise can only have 1 routine), then you will need to make "exercise_id" as the index for the RoutineExercises table. If you want a many-to-many relationships to be allowed (i.e. each exercise is allowed to have multiple routines), then set the tuple of (routine_id, exercise_id) as the index.
Let's say I have a Database with 3 tables: Keywords, Documents, and KeywordDocuments. KeywordDocuments has only 3 columns, KeywordDocumentID, KeywordID, and DocumentID.
The relationship between Documents and KeywordDocuments is the same as Keywords and KeywordDocuments, i.e. one-to-many.
Watching Julie Lerman's video on EF, she said that we don't need KeywordDocuments's entity in the model. How do I eliminate that entity while making sure that in the relationship will be respected in the underline database?
Thanks for helping
Remove the KeywordDocumentID column from the KeywordDocument table. It will then contain only the foreign key columns from the tables for which it represents a many to many relationship.
Create a new composite primary key on the KeywordDocument table which includes both the KeywordID and the DocumentID columns. This will replace the original primary key that you had on the KeywordDocumentID column - that key would have been deleted along with the column.
A table such as this will not result in an entity being generated in the model. Rather, both of the other entities (Keyword and Document in this case) will have navigation properties based on EntityCollection. Document will have a collection of Keywords and vice verca.