Hey there.

I'm planning on writing a giude/tutorial thing on o/r mappers, and how to use llblgen. The idea is to use this internally for developers yet to use llblgen.

One question I have been asked a few times by developers when i talk about or mappers is:

But don't you have to design your database differently when you use them?

Now obviously you dont need to design your database completely differently. You do however need to concentrate more on the db design, which is always a good thing, but I was wondering if there are key design decisions that might be influenced if you are using a or mapper.

As an example. We have "policy" records, in a policy table. There policy records are associated in a 1:m way with a number of things (e.g. sites, users, roles, etc). In some cases we ended up with a situation where associations could exist between 8 other things. To remove the need for 8 link tables, we had one table, called Policy_RelatedItem. Its fields were Policy_ID, Related_ID, and Related_Key. This last field allowed us to tell "with what" the associated was. It worked great for us previously...but now that we want to use or mappers, its not the ideal solution at all, and makes the relationshios hard to define etc...

I'd love to hear people's thoughts on this...should db design be affected by the choice to use llblgen? I know I saw some related blogs about this, so i'll try to dig those out....

Thanks!

IMO not "Everything" can be solved by ORM and LLBLGen (Unfortunately).

However, one time I built an accounting system. And there were 5 or 6 key values that made up a given "Type" of record. Basically, I had a journal of all invoices, invoice lines, adjustments, Receivable Lines, Payable Lines, etc.

I created a views to facilitate the data I needed. Often times, we needed to see an invoice with its outstanding payables, and just below it, we needed to see receivables for the same invoice. On and on and on.

So, once I defined a view to "show me data", I ran LLBLGen on it, and viola, done.

Another thing to note is that 3rd normal form isnt "Always" best for the useage. OLTP queries start to get slower as you move past 4 joins in a query. So sometimes a certain level of denormalization is an appropriate to assist speed. Denormalization coupled with triggers to maintain the denormalized data is even nicer in some scenarios.

I agree about the 3nf point. Sometimes it makes more app-sense to denormalise, I know of a few places in our db where it would help to slightly duplicate some data for the sake of the app performance.

In the point I made about having one "link" table that linked a record with loads of other records, I think that if there was one table per link entity, it would make an o/r mappers job easier, and as a result the generated code would be more useful to work with. The downside is the sheer number of tables to maintain in the database.