This question is locked. New answers and comments are not allowed.
Hey all,
I'm currently trying to choose and stuck to an ORM, lightweight but having minimal features that we require. And we're reading documentations and searching forums of alternatives. Telerik OpenAccess is the one probably we'll use.
As we switch to an ORM, we know that we have to partially change our way of thinking on database/model design. Up to day, we always preferred database-first approach and used our tiny wrapper class which implements ActiveRecord pattern. This sometimes caused us to move away from database normalization rules. The main reason underlying this approach was our concerns on report generation performance . In fact, we're not much complaining about this denormalization, but if we can't achieve the same structure with ORMs, we'll need your help about alternative to our model design .
First example is conditional associations. A table should be associated to one of 10 tables depending on a field value. In our application there are 10 transactions that affects balance of a client account. Using our design, we could generate report just from a table instead of consolidating data from 10 different tables with UNIONs. But, sometimes we should backreference the source transactions.
Another one is self referencing. We have hierarchical definitions of client groups. This table has a field referencing a parent group defined in the same table.
Thanks in advance.
I'm currently trying to choose and stuck to an ORM, lightweight but having minimal features that we require. And we're reading documentations and searching forums of alternatives. Telerik OpenAccess is the one probably we'll use.
As we switch to an ORM, we know that we have to partially change our way of thinking on database/model design. Up to day, we always preferred database-first approach and used our tiny wrapper class which implements ActiveRecord pattern. This sometimes caused us to move away from database normalization rules. The main reason underlying this approach was our concerns on report generation performance . In fact, we're not much complaining about this denormalization, but if we can't achieve the same structure with ORMs, we'll need your help about alternative to our model design .
First example is conditional associations. A table should be associated to one of 10 tables depending on a field value. In our application there are 10 transactions that affects balance of a client account. Using our design, we could generate report just from a table instead of consolidating data from 10 different tables with UNIONs. But, sometimes we should backreference the source transactions.
Another one is self referencing. We have hierarchical definitions of client groups. This table has a field referencing a parent group defined in the same table.
Thanks in advance.
2 Answers, 1 is accepted
0
Mehmet
Top achievements
Rank 1
Rank 1
answered on 01 Jul 2013, 06:24 AM
Well, probably the best solution is not associating the tables at all.
0
Hello Mehmet,
For the case with conditional associations, where the joined tables are not known in design time but only during runtime, it is indeed better not to define any relationships in the designer but use appropriate Linq queries (with joins) to combine data from different tables.
For self-referencing associations, there should be no problem to define them in the model directly. This way you will take advantage of the generated navigational properties and will be able to access more easily the referenced objects.
Hope that helps.
Regards,
Alexander
Telerik
For the case with conditional associations, where the joined tables are not known in design time but only during runtime, it is indeed better not to define any relationships in the designer but use appropriate Linq queries (with joins) to combine data from different tables.
For self-referencing associations, there should be no problem to define them in the model directly. This way you will take advantage of the generated navigational properties and will be able to access more easily the referenced objects.
Hope that helps.
Regards,
Alexander
Telerik
OpenAccess ORM Q2 2013 brings you a more powerful code generation and a unique Bulk Operations support with LINQ syntax. Check out the list of new functionality and improvements shipped with this release.