In a database data model, would a flatter model be more efficient, or too risky?

Question

Lets say I am creating a data model for an online seller. The company would have many warehouses across the country, just like Amazon.

(A picker is a person that works in the warehouse who picks merchandise from shelves, and packs the box for shipment.)

Here is my data model I created so far:

I thought of another way this could be done, a more flatter design: (The difference is in red.)

The disadvantage - there is a theoretical possibility the application could put bad data into the database. But perhaps I could trust the developers, who are senior level, to not do that.

The advantage - SQL queries for reporting are now simpler. If I wanted to query how much total sales we are getting from a specific vendor, now there would be one less table to join. I would no longer have to join the Product table. This makes queries simpler.

Is model #2 a good idea, or is the risk not worth it?

Answer 1

Flattening the hierarchy is a good idea for reporting systems but not for OLTP in general. The concept shares some properties of the schema design technique for OLAP and Data Warehouse applications and is commonly known as Star Schema. The more flat the hierarchy is, the easier it is to write and build a query. Also, queries could run faster.

The problem with such a design is that some business rules can't be detected on the daatabase level directly from the schema. For example, in the case of your second design, an Order row could have any combination of VendorID and ProductID whereas in the first design this can't happen.

If your database is shared only by your application (not an enterprise application) and you control the code that does the update and you are willing to cover such missing business rule, and you have large data volumes, the 2nd design could be valid in your case.

One important point for you to take care of, is that you have the lines representing most relationships are drawn in reverse. That is, when you have a one-to-many the FK the line with craw's feet shold be at the many's side.

Answer 2

When dealing with data that's for the lack of a better category, enterprisy... never try to flatten the database.

Database flattening is used only in real big applications where data isn't 100% integral. Where atomocity isn't guaranteed and doesn't need to be.

I say, stick to your original design. You'll be thankful later when you have to implement a lot of small changes across the design and code (maybe adding a couple of extra columns for different flags) in your various tables...

Also the most important concept in having everything related and not flat is that you make a change in one place and everything trickles down/up/sideways (depending on how you've set up the database constraints).

But with a flat approach, you have to always remember in which all tables do you have make changes, else your data breaks or your future 'reports' won't have accurate information.

Also, you can always use various ORM tools to make reporting easier. You never have to worry about joining tables... just use the tools .. then it's as simple as

table1->relation->columns in relation->more relation->column in third level relation to address any column..

There are lots of stand-alone ORM tools for various languages.