Should an entity map to its own database table?

Question

I'm doing some work using Azure and Idea Blade DevForce and I'm wondering what the best approach is in terms of mapping entities to database tables...

Should an entity have its own table in the database? Is there any performance benefit / detriment to doing this?

Say we have an "Order" entity, a "Product" entity, a "Customer" entity and an "Address" entity; what are the pro/cons of mixing these in one table vs. separating them all out? Obviously the db wouldn't be in 3rd normal form if we didn't separate, but does that matter when using MEF / DevForce?

As a second (less-contrived) example, what if we had an "Account" entity and a "User" entity; an account can have many users, but the users can only belong to a single account... That way, putting them all in one table doesn't duplicate any user data, but I (personally) still think this approach is plain wrong. Are there any reasons why it would be a benefit?

Answer 1

Depends on how much you like duplicating data, and whether you want anyone to take you seriously as a developer. Throwing everything into a heap is about the worst anti-pattern I can think of.

Say, for instance, you want to create 4 Orders for 2 Customers, with each Order containing 5 Products. Your Customer data alone is going to get repeated 10 times per Customer.

EDIT: I should note that my answer to the question is an emphatic "yes." I'd be interested in hearing arguments FOR the alternative...