I am using EclipseLink as JPA Provider. I want Eclipse Link to Generate my tables so I have used drop-and-create-tables as eclipse link ddl generation strategy in persistence.xml file.
My Question is as follows :
I want to implement Many to Many relationship.I have an auction table and an item table.
An auction can have many items and one item can be in many auctions.
When Eclipse Link Generated the tables, I saw that it had created four tables in the DB.
1) Auction 2) Auction_item 3) Item and 4) Item_auction.
Auction_item has two columns 1) Auction_id 2) item_id
Item_acution has two columns 1) Item_id 2) auction_id
So in all Eclipse Link has created two bridge tables on its own to map Many To Many relationship.
Can we not have a single bridge table having auction_id, item_id to achieve the same?
If we cannot, What are the reasons?
Thanks
You likely have two #ManyToMany mappings but are missing the mappedby indication on one side. This is used to indicate that one side uses the mapping information contained in the other side, and that the relationship is controlled at the database level by that side.
ie:
Auction class{
#ManyToMany
List items;
}
Items class {
#ManyToMany(mappedby="items")
List auctions;
}
Related
Title is the question. When should a relationship in an ER diagram be given its own table in a RDBMS? For instance, one mail courier(with attributes eid and surname) can deliver a number of packages but a package(attributes,pid, sent_By, going_to) can only have one mail courier. Would it make sense to make a table for the relationship called delivers(with an attribute of the time that the package was delivered)? or should the eid of the mail_courier and time_delivered from the deliver relationship be added to the package entity? Also, what would be an example when you would not want to add the attributes to the package entity?
I think what you are trying is to create a one-to-many relationship between two entities. And for that, there is no need to create a separate table; as you mentioned in your question, just add those two attributes to the package table.
Where you would need to create a separate table is when you want to achieve many-to-many relationship between two entities. For example, take twitter's followers. One user can have many followers and a follower can follow many users. You can't do that the relational way without creating a new table with just those two columns.
I have two tables that are related in SQL:
MasterPartNumbers MasterPartsLists
(pk) pn (one-> many) (fk) pn
desc parentAssemblyPn
(pk) partsListLineItemID
Note: MasterPartNumbers does share a navigational relationship to MasterPartsList, but the "many" side of the relationship (MasterPartsLists.pn) is not a primary or unique key. The same pn (part number) can belong to several different parentAssmeblyPns
Now, I want to make sure that any data that is added to my ObjectContext that belongs to either of these two entities is relayed to the other.
Question 1: how do I use the .Include() method to relay relevant information when adding new objects to the context (_context.MasterPartNumbers.AddObject(someEnumerable)) and applying .SaveChanges()?
I have a few tables that share only a few navigation properties and an ID.
I think Table per Concrete type inheritance would be interesting here.. (?)
It looks something like this :
Contact (Base, Abstract, not mapped)
- ContactID
- navigation properties to other tables (email, phone, ..)
Person : Contact (mapped to table Person with various properties + ContactID)
- various properties
Company : Contact (mapped to table Company with various properties + ContactID)
- various properties
Now for this to work, the primary key (contactID) should be unique across all tables.
2 options then:
- GUIDs (not a fan)
- an additional DB table generating identities (with just a ContactID field, deriving tables have FK), this would not be mapped in EF.
Is this setup doable ?
Also, what will happen in the ObjectContext ? What kind of temporary key does EF generate before calling SaveChanges ? Will it be unique across objects ?
Thanks for any thoughts.
mike.
We use a similiar construction with the folowing db design:
ContactEntity
ID
ContactPossibility
ID
Position
ContactTypeID
ContactEntityID
Address
ID (=PK and FK to ContactPossibility.ID)
Street
etc.
Telephone
ID (=PK and FK to ContactPossibility.ID)
Number
etc.
Person
ID (=PK and FK to ContactEntity.ID)
FirstName
etc.
Company
ID (=PK and FK to ContactEntity.ID)
Name
etc.
This results in the entity model in two abstract classes: ContactEntity (CE) & ContactPossibility (CP) and multiple derived classes (Address=CP, Email=CP, Person=CE, Company=CE). The abstract and derived classes (rows in the db ;) share the same unique identifier, because we use an ID field in derived classes that's a foreign key to the primary key of the abstract class. And we use Guid's for this, because our software has the requirement to function properly off-line (not connected to the main database) and we have to deal smoothly with synchronisation issues. Also, what's the problem with Guid's?
Entity Framework does support this db / class design very good and we have a lot of pleasure from this design.
Is this setup doable ?
Also, what will happen in the ObjectContext ?
What kind of temporary key does EF generate before calling SaveChanges ?
Will it be unique across objects ?
The proposed setup is very very doable!
The ObjectContext acts fine and will insert, update and delete the right tables for derived classes without effort. Temporary keys? You don't need them if you use the pattern of an ID for derived classes that is both primary key and foreign key to the abstract class. And with Guid's you can be pretty sure that's unique across objetcs.
Furthermore: The foreignKey from CP to CE will provide every CE (Person, Company, User, etc.) with a trackable collection of ContactPossibilities. Which is real cool and handy.
Hope this helps...
(not enough space in the comments section)
I've been running some tests.
The thing is you're OK as long as you ONLY specify the subtype you're querying for (ex. 'Address' in your case).
But if you query for the base type (even if you don't need the subtypes info), ex. only ContactPossibility.ID, the generated SQL will UNION all subtype tables.
So querying your 'trackable' collection of ContactPossibilities can create a performance problem.
I tried to work around this by unmapping the base entity and split the inherited entities to their own table + the common table, basically transforming the TPT into TPC : this worked fine from a conceptual perspective (after a lot of edmx editing). Until I realized this was stupid... :) Indeed in that case you will always need to Union all underlying tables to query for the common data...
(Though I'm not sure in the case described at the end of this post, didn't pursue to test it)
So I guess, since mostly I will need to query for a specific type (person, company, address, phone,..), it's gonna be OK for now and hoping MS will come with a fix in EF4.5.
So I'll have to be careful when querying, another interesting example :
Let's say you want to select a person and then query for his address, something like (tried to follow your naming) :
var person = from b in context.ContactEntities.OfType-Person-()
where b.FirstName.StartsWith("X")
select b;
var address = from a in context.ContactPossibilities.OfType-Address-()
where **a.ContactEntity == person.FirstOrDefault()**
select a;
this will produce a Union between all the tables of the Contact derived entities, and performance issues : generated SQL takes ContactPossibility table and joins to Address on ContactPossibilityID, then joins a union of all Contact derived tables joined with the base Contact table, before finally joining a filtered Person table.
However, consider the following alternative :
var person = from b in context.ContactEntities.OfType-Person-()
where b.FirstName.StartsWith("X")<BR>
select b;
var address = from a in context.ContactPossibilities.OfType-Address-()
where **a.ContactID == person.FirstOrDefault().ID**
select a;
This will work fine : generated SQL takes ContactPossibility table and joins to Address on ContactPossibilityID, and then joins the filtered Person table.
Mike.
So I am in the process of redesigning a small database (and potentially a much larger one) but want to show the value of using revisions / history of the business objects. I am switching the data from Access to MSSQL 2008.
I am having a lot of internal debate on what version of "revision history" to use in the design itself - and thought I had decided to add a "RevisionId" to all tables.
With this design - adding a RevisionId to all tables we would like tracked - what would be the best way to create Navigational Properties and Relationships between two tables such as
| Vendor | VendorContact |
where a Vendor can have multiple contacts. The Contacts themselves will be under revision. Will it require custom extensions or am I over thinking this?
Thanks in advance.
So presumably your key for the Contact table would now be a (generated unique ID + a Revision Id).
And there will be a FK relationship between Vendor and Contact using just the unique ID. So it will be a 1:many mapping.
And a simple request to get the current contact will become vendor.Contacts.OrderByDescending(c => c.RevisionId).First() or you can get the entire revision history for that contact if you want.
OR are you trying to track how that contact has changed over time (i.e. it was person A and not it's person B)? i.e. does the relationship itself need to have a RevisionId on it?
Or are you perhaps trying to track both revisions to the relationship AND revisions to the contact it points to?
vendor.VendorContacts.OrderBy...().First().Contact.OrderBy...().First()
This could get ugly pretty fast!
I'm having trouble wrapping my head around how to set this up. I have two tables:
Projects
Sections
1 project can belong to many sections.
1 section can have many projects.
How would I go about setting this up, would this be a many to many relationship or one to many?
Would it best if I created a lookup table?
would this be a many to many relationship or one to many?
It's regarded as many-to-many, because many projects can refer to many sections.
You'll need to implement a table that sits between projects and sections, using foreign keys from both to be the primary key. Example:
PROJECTS_SECTIONS_XREF table
PROJECT_ID, pk, fk
SECTION_ID, pk, fk
The naming convention is up to you, but I recommend something informational by using the names of both tables involved. Corrollary, cross references (xref), lookup, etc. There's been two questions regarding the naming convention in the past week or so - all the names are synonyms, choose whatever you like.
This is a simple 1-to-many relationship . The 2 requirements you stated above amount to the same thing. No lookup table is required. In your sections table you simply have a fk back to the projects table
Create a relationship table... let's call it ProjectSections, with fields ProjectId and SectionId. You create the relationship between a project and a section in ProjectSections by creating a record with the ProjectId and the SectionId.
ProjectSections then links the Projects and Sections together.