SQL Server表设计建议（Entity Framework代码优先，C＃）

Question

I have started working on a website created by another development house. The database structure was created using Entity Framework's code first approach. In the C# code we have something along the lines of:

public class MainBusinessObject
{
    ...
    public SubBusinessObject { get; set; }
}

public abstract class SubBusinessObject 
{
    ...
}

public class SubBusinessObjectTypeOne : SubBusinessObject 
{
    ....
}

public class SubBusinessObjectTypeTwo : SubBusinessObject 
{
    ...
}

...

There are 6 SubBusinessObject types. The smallest has one property, the largest around 50. The SubBusinessObject abstract class defines an additional 17 properties. The MainBusinessObject has around 35.

What sort of real world entities do these represent? If MainBusinessObject held the data for, say, FruitForSale , then SubBusinessObject would represent Fruit , and SubBusinessObjectTypeOne could be Apple , SubBusinessObjectTypeTwo could be Orange and so on.

Both the MainBusinessObject and SubBusinessObject classes link to other database objects (such as the source and location of the items). All of these entities map directly to SQL Server tables.

As a function of this design queries dealing with a MainBusinessObject are slow. For instance it takes around half a second to retrieve the data for a single MainBusinessObject (and nearly 5 seconds on first run). I have tried making multiple calls however the performance ends up being roughly the same. The site in general suffers from poor performance and this is a key area.

Please note that I am not a DBA, I am just a developer (and we all know how well developers design databases...). However the table design appears overly convoluted to me, though I could well be wrong. Would flattening these tables into a single table be considered bad practice? Any advice around dealing with these sorts of issues would be very much appreciated.

Answer 1

Would flattening these tables into a single table be considered bad practice?

No, that would not be considered a bad practice.

EF 6 supports two strategies for storing an inheritance hierarchy like this: Table-per-Type (TPT) and Table-per-Hierarchy (TPH). TPT storage is initially attractive as each subtype gets its own table in the database. In TPH a single table stores all the attributes, with a discriminator column.

But, as I think you are discovering, joining these tables at runtime can be expensive.

TPH is generally considered a best-practice, as less prone to performance problems. And so, no, flattening all these tables is not considered a bad practice. In fact TPT has not yet been implemented in EF Core, for this reason.

You should create a new version of the database using TPH and copy data from the current database to the new one for testing. If you want to transition your read database to TPH, here's a helpful post on how to do that with a Migration. Entity Framework Code First Convert TPT to TPH