I’m working in mid-size .NET application which has a very very bad if not worst database design, almost of tables don’t do normalization and complex table design.
E.g. I have one table to keep track of stock movement and every times I modify this table I need to update current stock table. In my opinion this is a bad design, because I can use SUM when I want to know current stock.
Another example, Every time I insert new stock movement data, I don’t insert to stock movement table directly, instead I insert data to temp stock movement and then I use tricker to copy that data to stock movement and other relate tables (may be update customer credit).
I try to adopt ORM with this application but its seem too hard for me, I need a couple of hour to create mapping-class and a couple day for test its, because not-normalize and vague data persistence.
I want to know, Can ORM reduce problem from bad database design like this? If yes, how can I do that?
P.S. I can’t change database design at all, because almost of members in my team have no idea about database concept.
I don’t think so. ORM and objects aren’t magic. If you put them on top of a bad design, it’s still a bad design.
If it’s not imperative that every stock update appear right away, you can queue them up and do “write behind” in an asynchronous way. But that’s just papering over a potential problem.