quick question here guys.
I'm working with an older database, which had no relationships adn am now trying to make it as consistent as possible.
the code that I'm porting had some quirks which led to some situations where I cannot enforce the relationship (PK <-> FK). I was wondering if this enforced relationship is a requirement for Linq to SQL?
thx for the help :)
The auto-generated LINQ to SQL classes (found in the .cs file underneath the dbml) are partial, so you can add additional properties and functionality as necessary.
The explicit relationships in SQL are used by LINQ to add properties - for example, if you have a Customers table and an Orders table with explicit relationships, LINQ will be able to put a strongly-typed Orders collection as a property on the Customer object. Without that, it will only be able to go as far as putting a CustomerID (int or whatever) on the Order object.
In the absence of explicit relationships, you can manually add properties and attribute decorations to the auto-generated entity classes. I strongly recommend putting as much as you can in a partial class so you changes aren't lost if you re-generate the entity classes.
The relationship in the DB is not a requirement. It is used by the designer to infer the relationship "properties" you get automatically, but you can add your own and indicate which scalar properties identify the relationship in both tables. (Right click on the designer, choose "Add Relationship" and identify both tables and columns, or drag/drop with the "relationship" tool)
Be careful though. If your problem is that the application stores "placeholder values" to identify "no relationship" (like a zero value that has no counterpart in the primary key table), you might end up with exceptions being raised if you try accessing the corresponding member in the code.
If the problem is that the original application stores stuff in the wrong order (therefore preventing you from enforcing an FK constraint), but when all is said and done you have consistent data, then you should have no problem.
as I commented on one of the possible answers...
the question is much more simple:
does linq allow the fetching of data on relationships on which consistency is no enforced? I'm not talking about adding more props...
this would mean functionality for the values that DO have the correct PK<->FK relationship I think (as I said I haven't tested this, maybe some of you have?). and what would this do for values that don't exist? raise a nullreference?