I use hibernate as the framework for springboot CUBA operations. But I have a problem, our workout information and recipe information are coming from external API. This means that I only need to store the recipe and workout ids in the database. The database structure is as follows.
DB sturucture
As the data is provided by the API, we have not created corresponding entity tables for workouts and recipes. But then the problem arises. What should be done with the join table in this case. I mean the premise of #manytomany is that two entity tables are needed, and we only have entity tables for users. Even if we use a joint primary key, there is still a need to add user_id as a foreign key in the joint primary key. How can we mark user_id as a foreign key without a workout or recipe entity table?
Your question is quite confusing but I'll try to provide an answer for what I understood.
If the data is completely external, you can map an element collection consisting of ids only:
#Entity
public class User {
// other fields
#ElementCollection
#CollectionTable(name = "recipse_user")
Set<Long> recipeIds;
#ElementCollection
#CollectionTable(name = "workout_user")
Set<Long> workoutIds;
}
Related
I'm porting a MySQL database to Core Data for a Mac OS app. I have two many to many tables in my database. In addition to containing the foreign keys, there are a few data columns. Is it possible to add attributes to a many to many relationship in Core Data? It doesn't look like it to me. My fallback is to replicate the linkage table in Core Data. Are there any problems doing this?
An example:
A record has one or more artists performing on it.
An artist performs on zero or more records.
The linkage table row contains a foreign key for the record, a foreign key for the artist, the instruments the player performed with, and a notes column that adds additional information such has which track the artist performed on.
You are correct: relationships themselves cannot have attributes. And you are on the right track in modelling the linking table as an intermediate entity. This approach is alluded to in the CoreData Programming Guide section on "Modelling a relationship based on its semantics". In their case, they model a (reflexive) many-many relationship from Person to Person using an intermediate FriendsInfo entity with a ranking attribute.
In your example, you might have a Record entity, an Artist entity, and an intermediate Appearance entity. The Appearance entity would have attributes for Instruments and Notes, and (to-one) relationships to Record and Artist (each with a to-many inverse).
The slight downside is that you have to create the Appearance object in order to link a Record object and an Artist object, rather than just adding them to the relevant relationship. You will also have to watch for uniqueness of the combination of Record/Artist, if that's important to you: by default there could be many Appearances for the same Record and Artist.
My organization works on Spring MVC with Hibernate. We always specify foreign key constraints in mapping file, like for person and contactList in Person.hbm.xml
<set name="ContactList">
<key column="PersonId" foreign-key="Fk_Peson_Contact"/>
<one-to-many class="Sample.Model.Contact"/>
</set>
This mapping will create one-to-many relationship between Person and Contact, and keep PersonID as foreign key column in the Contact table.
But, now organization has decided not to mention any kind of relationship in mapping file, means in above case Person mapping will not have any kind of one-to-many mapping instead of this Contact mapping will have property <property name="FK_PersonID"/> which will create column to hold personID. In this scenario table Person and Contact will look same but the difference is their is no relationship between Person and Contact coz no mapping is specified.
In such case if we want to fetch person's contactList then we have to fire two queries one to fetch person another for its contactList. let suppose we want to fetch personList with its contactList then we have to For loop on PersonList and fetch its ContactList which will fire number of queries.
When i ask why not specify relationship then senior said ,
If foreign key is in DB then we can't do slicing and partitioning.
When we fire join query DB takes more time to execute it.Which may slow down DB server.
But,my question is -
if i do For looping on personList then it will fire number of queries to fetch contacts is it feasible?
can such looping slow down application or application server?
what if i want to fetch personList with its conatctList,AddressList,QualificationList, Does this cause n+1 issue?
Which Scenario is more beneficial whether to specify mapping or not.
Well, I one of the early demos of partitioning in (MS) SQL by microsoft they showed a query which selected from a partioned table with data populated across several partions, and it used its indexes and stats to not even bother accessing partitions that had no (relevant) data. Of course if you dont have a fk constaint then it cant use the index and stats to know the fk conforms. I'd be fairly sure it would be covered by Kalen Delaney in her book (for the relevant version of MSSQL). The key is that the stats will contain the necessary information to prevent unnecessary seeks. The demo actually used a union to easily demo the effect.
I'm using VS 2010, Entity Framework 4.3 and MySql.Data.Entity v6.3.5 to work with a MySQL DB with a couple dozen tables. I use the ADO.NET DbContext Generator.
Everything works well enough other than two tables don't get Entities created for them. Both have a similar structure in that they have a composite key composed of foreign keys to other tables. So, one is a region_flavor table that maps the (ice cream) flavors assigned to a particular sales region. It looks like so
region_flavor
-------------
RegionId INT(10) PK NN
Flavor VARCHAR(64) PK NN
RegionId is a FK to the regions table and Flavor is a FK to the ice_cream table.
There's another table with essentially the same situation.
When I do an "Update from Database", I see that there is, in the Model Browser, the table region_flavor listed under my IceCreamModel.Store\Tables / Views folder. But under my IceCreamModel\Entity Types folder there's no Entity Type.
I don't receive any .edmx errors when I do the update from the DB.
Perhaps I'm missing something here. Ideas?
I can post more info if that's helpful.
It is normal behavior. This is junction table used to model many-to-many relation in database. If it doesn't contain any additional column EF doesn't need to map it to entity because many-to-many relation is modeled directly and translated to table rows internally by EF.
Database tables:
Tutor( {PK}tutorId, name )
Module( {PK}moduleId, name, {FK}tutorId )
Relationship Tutor -> Module (OneToMany)
Questions:
If you create the domain model
classes with JPA annotations, the
corresponding database tables are
auto-created with the same columns as the annotated fields of the class?
Do you create the database first
and then the JPA classes with the
same fields as the database table
columns?
How do you model foreign key constraints with JPA
(1) and (2) are depended on your situation. you can create domain model class first and it will generate table and columns which are the similar to the fields. In addition, you can establish a database first (it is easy to design and have better view of the whole database.), then map the tables to your domain class.
about (3) you can try this link
Hopefully someone can shed some light on this issue through either an example, or perhaps some suggested reading. I'm wondering what is the best design approach for modeling tables after their class hierarchy equivalencies. This can best be described through an example:
abstract class Card{
private $_name = '';
private $_text = '';
}
class MtgCard extends Card{
private $_manaCost = '';
private $_power = 0;
private $_toughness = 0;
private $_loyalty = 0;
}
class PokemonCard extends Card{
private $_energyType = '';
private $_hp = 0;
private $_retreatCost = 0;
}
Now, when modeling tables to synchronize with this class hierarchy, I've gone with something very similar:
TABLE Card
id INT, AUTO_INCREMENT, PK
name VARCHAR(255)
text TEXT
TABLE MtgCard
id INT, AUTO_INCREMENT, PK
card_id INT, FK(card.id)
manacost VARCHAR(32)
power INT
toughness INT
loyalty INT
TABLE PokemonCard
id INT, AUTO_INCREMENT, PK
card_id INT, FK(card.id)
hp INT
energytype ENUM(...)
retreatcost INT
The problem I'm having is trying to figure out how to associate each Card record with the record containing it's details from the corresponding table. Specifically, how to determine what table I should be looking in.
Should I add a VARCHAR column to Card to hold the name of the associated table? That's the only resolution that my peers and I have come to, but it seems too "dirty". Keeping the design extensible is the key here, allowing for the easy addition of new subclasses.
If someone could provide an example or resources showing a clean way of mirroring class/table hierarchies, it would be most appreciated.
Google "generalization specialization relational modeling". You'll find several excellent articles on the subject of how to model the gen-spec pattern using relational tables. This same question has been asked many times in SO, with slightly different details.
The best of these articles will confirm your decision to have one table for generalized data and separate tables for specialized data. The biggest difference will be the way they recommend using primary and foreign keys. Basically, they recommend that specialized tables have a single column that does double duty. It serves as the primary key to the specialized table, but it's also a foreign key that duplicates the PK of the generalized table.
This is a little complicated to maintain, but it's very sweet at join time.
Also keep in mind that DDL is required when a new class is added to the hierarchy.
Basically don't.
Forget about class hierarchies, storage models, and anything that is specific to your app and your particular app language. Unless you want to use the RDb as a mere storage location for your files, a dependent slave.
If you want the power and flexibility (specifically extensibility) of the relational Database, then you need to model it independent of any app, and using RDb principles, not app language requirements. Leave your app context behind for a while and design the database as a database. Learn about them. Normalise (eliminate all duplication). Learn about the structures and rules, and implement them. When you do that, your queries and your "mapping", will be effortless. There will be no "impedance". Use the correct datatypes and there will be no mismatch.
The structure you require is an ordinary subtype-supertype. Those are Relational Database terms that have been in existence for over 30 years in the RM, and over 23 years in Relational Database products. No need to call them funny new names. Wikipedia is not an academic reference.
Given your tables, which are quite correct as a starting point (you've Normalised automatically), you need:
Rename Card.Id as Card.CardId
Remove the ids for the subtypes, they are 100% redundant; the CardId is both the PK and the FK.
Add a discriminator Card.CardType CHAR(1) or TINYINT. This will identify which subtype to join with, when the CardType is not known.
It appears you do not fully understand the concept of Foreign Keys, so that would be good to gear up on first. It is implemented here in its simple, ordinary form:
ALTER TABLE MtgCard
ADD CONSTRAINT Card_MtgCard_fk
FOREIGN KEY (CardId)
REFERENCES Card(CardId)
The relation between Card and MtgCard or PokemonCard is always 1::1. The supertype is complete only when there is a Card plus { MtgCard | PokemonCard } with the same CardId. In your case there can be only one subtype, easy to enforce with a simple CHECK constraint.
In other cases, more than one subtype is quite legal.
The subtypes there are Person Is a Teacher or Person Is a Student
In Relational Databases there is no concept of joining "from" or "to" (or up/down or left/right), those notions are only there to assist us humans; you can start with any table/key you have, and go to any table you need. The tables in-between are demanded only in the absence of Relational Identifiers (ie. where additional Surrogates, ID columns, are used as PKs instead of meaningful natural keys).
In the example, using your terms, you can go straight from Enrollment to Person (eg, to grab the LastName) or to Course (to grab the Name) without having to visit the intermediate tables; the relation lines are solid.
.
Now, class hierarchies ("Is" or "Is a") and anything else, are simple and effortless.
Quick Reference to Standard Relational Database Diagrams.