Many to Many. If you have one of these relationships in your schema, you've not finished the design phase. Please do not proceed to bodge up some secret-sauce solution to abstract it away; instead look for the data that potentially lies in the link entity. 9 times out of 10, it's useful and part of the system you are modelling. Code first is for people who don't want to "waste time" on proper schema design. They'd rather just write code. Then more code to bodge round the shortfalls in schema design which not "wasting time" on the design phase has caused. Rinse and repeat. In fairness, many companies have made fortunes selling bad design then the fixes for it. Step forward Microsoft and SAP for a special award. It's a good certain job software "engineers" (sic) don't design aircraft or automobiles.
@@picflight classic join table called CarFeature CarId FeatureId /* Other data here - perhaps: qty of feature required price application instructions */ Given that not every feature may be available on every car model, this is possibly completely central to the database design. Many to many table relationships always imply a join table, and more often than not conceal important data in that table. Microsoft's code first is an abomination. Data design is the critical phase - it's the 'cake'. All the apps that hang off the DB are the icing and candles!
Perfect in a 100% code First scenario
Could you tell me please, how to add custom fields to association table?? On many to many relationships,
thanks very much!
th-cam.com/video/BIImyq8qaD4/w-d-xo.html&ab_channel=dotNET
This is where they are doing exactly what you asked. They call it "Payload" properties. th-cam.com/video/BIImyq8qaD4/w-d-xo.html
M2M table as DbSet not allowed why ?
Is it possible to configure the DbSet to work as dictionary just wondering if i could save some steps by moving it to dictionary lol
thanks
nice
Maurycy sounds Polish :P
Many to Many. If you have one of these relationships in your schema, you've not finished the design phase. Please do not proceed to bodge up some secret-sauce solution to abstract it away; instead look for the data that potentially lies in the link entity. 9 times out of 10, it's useful and part of the system you are modelling.
Code first is for people who don't want to "waste time" on proper schema design. They'd rather just write code. Then more code to bodge round the shortfalls in schema design which not "wasting time" on the design phase has caused. Rinse and repeat. In fairness, many companies have made fortunes selling bad design then the fixes for it. Step forward Microsoft and SAP for a special award.
It's a good certain job software "engineers" (sic) don't design aircraft or automobiles.
Car model has Features
Feature has Cars
Many to Many?
class Car
{
Id
Name
}
class Feature
{
Id
Name
}
@@picflight classic join table called CarFeature
CarId
FeatureId
/*
Other data here - perhaps:
qty of feature required
price
application instructions
*/
Given that not every feature may be available on every car model, this is possibly completely central to the database design. Many to many table relationships always imply a join table, and more often than not conceal important data in that table.
Microsoft's code first is an abomination. Data design is the critical phase - it's the 'cake'. All the apps that hang off the DB are the icing and candles!
Java world: do not make an attempt to try this, it will be a painfull realization :)
Hi