I have several tables that all reference the same lookup table. Is it generally a good idea to attach the BelongsTo attribute to each table that references a FK from a lookup table? Or should I model the foreign keys as a property and simply link the two tables while constructing my detached criteria?
Not sure I understand the question, but if you're asking whether to do this:
[BelongsTo("id_lookup")]
public virtual Lookup Lookup {get;set;}
or this:
[Property("id_lookup")]
public virtual int Lookup {get;set;}
The answer is: use the first one.
Related
I'm working on a Database in which I'm trying to deduce the best ways to apply inheritance.
So far I was having 2 subclasses from an Entity, and I asked in Extended Entity-Relationship Model to tables (subclasses) about how to implement it on relational tables.
I decided to go with Concrete Table so I created 2 tables, one for each subclass of the Entity. I encountered 2 problems:
My primary keys were id int primary key autoincrement, which means the first row of each table is gonna have id = 1. So the key isn't actually unique, So when referencing it from another tables, there is no way to know which of the 2 table subclasses are we referencing (unless I add an unnecesary(?) extra column.
When adding a Foreign Key that references said id, the foreign key is supposed to referece both subclasses tables, but I don't know if that is even possible.
Any ideas or opinions about how this could be done could help a lot. thanks
It would probably make sense to have the child class tables reference the parent class, instead of the other way around. Then you can have an id column on the Entity table which is unique and foreign keys from the children to their parent instances. Presumably this will help when you want to use the data to instantiate an object in your code as well, since you should know which class you are instantiating and only care about its ancestors, not its children.
I'm trying to set up an EDM on an existing SQL Server infrastructure, and came across a problem.
The EDM will not resolve a PK-FK relationship to a composite foreign key.
My DB table structure looks something like this (names changed to protect the innocent):
I have a PERSONS table containing an INT column called PerID (PK)
I have an OFFICE table containing an INT column called OffID (PK)
I am tying these tables together using a table called OFFICEPERSONS, creating a many-to-many relationship between PERSONS and OFFICE. This table has two INT columns, PerID and OffID, which together form a composite primary key.
I have a table called OFFICELOCATION that contains two INT columns, LocID and OffID. These two columns comprise a composite primary key. Additionally, OffID is also a FK to the OFFICE table.
Finally, I have a table called OFFICEPERSONSLOCATION. This table has three INT columns: PerID, OffID, and LocID. All three columns comprise a composite primary key. LocID and OffID provide a FK relationship to OFFICELOCATION, and OffID and PerID provide a FK relationship to OFFICEPERSONS.
With me so far? Hopefully, I haven't lost you yet. When all is said and done, my structure looks like this:
This structure works great in SQL Server. In EDM? Not so much. It will NOT allow me to construct the relation between OFFICEPERSONSLOCATION and OFFICEPERSONS. I get the following error:
Error 6037: Foreign key constraint 'FK_OFFICEPERSONSLOCATION_OFFICEPERSONS' has been omitted from the storage model. Column 'OffID' of table 'Model.Store.OFFICEPERSONSLOCATION' is a foreign key participating in multiple relationships. A one-to-one Entity Model will not validate since data inconsistency is possible.
Huh? Data inconsistency?!? How?
How do I get my entity framework to recognize this?
I agree that it is the entity framework's problem, and the problem is stupid. Even if you have the UPDATE CASCADE to "no action", it is not like you could create an inconsistency, but no, it claims that you can somehow.
In any case, in this situation, if you are willing to use surrogate keys instead of composite keys, you can get around this, because the only place to change the ID reference is in the main table.
In this case, OffID could be "inconsistent", but by using ID's in the OFFICEPERSONS and OFFICELOCATIONS tables (and therefore reference in OFFICEPERSONSLOCATION), you are forced to have the OffId managed in its primary table.
In ORMLite, how can I define a constraint (foreign) to another table, which is not linked by it's integer id, but by any other field, i.e. a varchar/string field, which isn't the PK.
For example, referring to the ORMLite sample code, where an 'order' entity is linked to an 'account' entity. In the example, the order is linked to the account by it's id column (I guess by default), which is the PK.
Instead of setting up the constraint from 'order.account_id' to the 'account.id' column, how can I set it up from something like 'order.account_name' to 'account.name' column instead?
I was looking for something like a foreignColumnName annotation, but unfortunately it doesn't exist, for a one-to-one relationship.
Here's the java code of the ORMLite examples:
Order.java
Account.java
I couldn't find any info in the documentation.
(The reason why I need it is that I have an existing db, not created by ORMLite automatically, which has obviously not been setup properly nor halfway normalized, but I need to work with that existing one, including it's existing column names and constraints.)
I was looking for something like a foreignColumnName annotation, but unfortunately it doesn't exist, for a one-to-one relationship.
Edit:
This feature was added to ORMLite in version 4.36. The concept of foreign objects was a new construct at the time. See the javadocs on the field here. To quote:
public abstract String foreignColumnName
Name of the foreign object's field that is tied to this table. This does not need to be specified if you are using the ID of the foreign object which is recommended. For example, if you have an Order object with a foreign Account then you may want to key off of the Account name instead of the Account ID.
NOTE: Setting this implies foreignAutoRefresh() is also set to true because there is no way to refresh the object since the id field is not stored in the database. So when this is set, the field will be automatically refreshed in another database query.
Here is the scenario.
STUDENT, FACULTY are sub-classes of PERSON entity, and they have specialized attributes.
Normally, we store common attributes in PERSON table (with p_id as pk) and store specialized in the subclasses. We map the subclass to the superclass using p_id by creating a column in the subclass.
However, is it acceptable to do something like following.
Instead of p_id as the mapping attribute in subclass, can we use something else belonging to the superclass which is unique but not pk.
NOTE: The EER Diagram (conceptual design) still remains same!
It's just a foreign key, even for supertype/subtype schemas. You can reference any column that's declared UNIQUE.
I'm pretty sleepy, so I'm not sure how that would affect the updatable views. I don't think it would affect them, though. (Assuming you're using them. Some don't bother.)
I have two views: one is a normal view built from one table with an integer ID and other columns for the record (let's call it View1). I have another View (View2), which has an integer ID column and a second column named "table" (type: varchar). That second column contains the name of the table to which the ID column is related: So, if View2 contains an ID of 999 and its "table" column contains the value "View1", that means the record referenced is ID 999 from View1.
Far as I can tell, DBML only allows for one-to-one or one-to-many relationships based on explicit column references; I'd rather express the relationship as a one-to-one based on the ID column AND View1.table being equal to "View2".
Is this possible? I know I can simply do an outer join in the linq query, but I'd rather avoid that if possible. Thanks!
It's not possible. The linq2sql mapper allows for mapping explicit foreign key relations, but if you don't actually have a foreign key relationship in the database, it's not possible for L2S to "infer" the relation in any way.