I want to know what really is the difference between EntitySet and EntityRef in LINQ-to-SQL. As per what I a seem to have understood, EntitySet is one-many or many-many relation and EntityRef is one-one. Correct me if I am wrong.
If the associated class is the many (child) side of a one-to-many relationship, the many class will be stored in a collection of the many classes, where the type of the collection is EntitySet , and T is the type of the many entity class. This collection will be a member variable of the one class.
If the associated class is the one (parent) side of a one-to-many relationship, a reference to the one class will be stored in a variable of type EntityRef , where T is the type of the one class. This reference to the one class will be a member variable of the many class.
therefore, EntityRef & EntitySet act one-to-Many relationship,EntitySet act the many in parent and EntityRef act as One in Child.
recently caught myself in the same doubts, so according to this answer you are right
Related
if you have 2 entities (teacher) and (student) both of them has a common attribute so I don't want to repeat the attributes on each table eg (name, age, address, mobile etc..)
so can I make supper class called human with two subclasses one for teacher and second for the student ?
if that valid -> how to connect the two subclasses with the super class? should I use flag of foreign key?
and for retrievingdata, how to do so as per half of the data on subclass and another have is on the supper class ?
thank you
I have different kind of actors:
Parents;
Subsidiaries;
Insurers;
Brokers;
for each of the actors, there will be users with a personal account and user role.
I need to register the address and other (entity specific, including foreign keys) info into a table, which could be done by defining one "actor_tbl" and specifying the type of actor with an id.
However, the four types of actor have interrelations, which means that one parent can have multiple subsidiaries, one insurer can have multiple subsidiaries, one broker can have multiple parents, etc...
From this point of view, it would make more sense for me to create a separate table for each of the actor types, and create many-to-many relationships to make the right combinations. It think that it may also increase general readability and reduce the possibility for errors (all entities would be clearly separated from one another).
However, doing so takes away the principle of storing all entities with similar characteristics into a single table.
How would you take on this problem? What is the most recommended way to implement this structure?
You can see a superclass/subclass relationship between Actor and the four kinds of actors. The first point here is to clarify the constraints on this relationship. From your description, I'm assuming the participation is mandatory (every Actor will be also a member of a subclass) and the subclasses are disjoint (e.g. a Parent cannot be a Broker, and so on).
In this case, you'll need four relations, one for each subclass.
If instead the participation is optional (some Actor may not be a member of any subclass), you'll need a relation Actor(ActorID, ...) to store all the attributes in common between the subclasses (e.g. address), then one relation for each subclass, which will look like:
Parent(ActorID, ...)
Subsidiary(ActorID, ...)
Insurer(ActorID, ...)
Broker(ActorID, ...)
For these four relations, ActorID will be both primary key and foreign key referencing Actor(ActorID). The dots represent the attributes which are peculiar to the specific entity (as mentioned before, the common attributes will be in the Actor relation).
For Actors which are not member of any subclass, you just store the record in the Actor relation. For Actors which are instead member of a subclass, you'll store the record in Actor and in the specific subclass relation.
In all cases, relationships between the subclasses will be modelled depending on their cardinality.
If the disjointness between subclasses is different, i.e. non-disjoint subclasses, then the story is different.
I have two classes namely;
-------------- -------------------
class A class B
-------------- -------------------
int c
-------------- -------------------
-------------- -------------------
class A is responsible for taking input from user, and class B is responsible for storing input token by class A.
What should the relation be between them?
There are direct relations between them:
class A function takes input then this input is directly stored in class B.
One of class A's functions is friend of class B.
There are three possibilities:
A could access B (perhaps via an interface) to store the data it produces;
B could access A (perhaps via an interface) to fetch the data it stores;
They could be unrelated, with higher-level business logic fetching data from A and storing it in B.
The third would be my preference, since it makes the objects self-contained and easier to test in isolation, and more flexible since they are not constrained to act together in a particular way.
With the limited info provided, I am assuming a scenario here:
Since you want Class A to be storing/setting some data residing inside of an object of Class B, probably Class A would need to use a setter method from Class B. This is a 'uses' relationship and could be categorized as association relationship.
If class A is also responsible to create instances of Class B, then the relationship would be aggregation.
The entity which participates in the 1:0+ relationship is the parent entity.
Is that correct?
Update:
No, this is wrong.
In a 1:1 relationship, you just have one table. There's no distinction. The attributes must apply to both types of entity.
However, in an optional 1:1 relationship, often called 1:0+ or "one to zero or one" relationship, the child would be the optional one, not the parent.
In short, there will always be a parent.
In your image, there's an optional one-to-one from staff to notebook, i.e. a staff member may have zero notebooks or one notebook. There's also a one-to-one relationship from notebook to staff, i.e. a notebook must have exactly one member of staff as an owner.
Here's a diagram to help you understand:
I'm playing around with LinqToSQL using an existing multi-lingual database, but I'm running into issues mapping a fairly important one-to-one relationship, so I suspect I am using the feature incorrectly for my database design.
Assume two tables, Category and CategoryDetail. Category contains the CategoryId (PK), ParentId and TemplateId. CategoryDetail contains the CategoryId (FK), LanguageId, Title and Description (in the appropriate language), with a combined PK of CategoryId and LanguageId.
If I drag-and-drop these tables into the LinqToSQL designer, the resultant object model has Category with a collection of CategoryDetail objects, which should never be the case. I'd like to be able to filter on LanguageId at the DataContext level, meaning that the whole Category is encapsulated within Category.CategoryDetail, not all language version encapsulated within Category.CategoryDetails.
This database worked fine on my old object library (an old-school custom BOL and DAL), but I fear that LinqToSQL would require this to change in order to give me the required result.
What is the best way to make this relationship (and language filtering) as seamless as possible?
You can view properties of the association. (Right click on the line representing the association and show properties.) The properties will tell you if it is a one-to-one or one-to-many relationship. This is reflected in code by having either a single entity association (one-to-one) or an entity set association (one-to-many).
I would have to assume cant be a true 1 to 1. Sounds like you have a PK of CatID and Lang ID on the Cat Details table. That would explain why its putting a collection. I could be wrong as you didnt mention the PK's of the CatDetails table
EDIT: A combined Pk of CatID and Lang ID makes that a 1:m relationship, and Linq to SQL is actually doing the correct thing. The only way it could possibly be a true 1:1 is if you had a lang ID on the cat table as well and that was part of the FK. I htink you may have to rethink what you want to do, or how you want to implement it.
I think LINQ to SQL models the database structure directly.
You have two tables so it creates 2 objects.
Have you had a look at LINQ to Entities this allows you to create another layer above the database strucure to make for more readable classes.
Since you don't have a 1:1 relationship the mapping alone will not provide the desired functionality. However it is easy to provide a method in the parent auto-generated class that does the job:
public partial class Category
{
public IEnumerable<CategoryDetail> GetDetailsByLanguage(string langID)
{
return this.CategoryDetails.Where(c => c.LangID == langID);
}
}