views:

24

answers:

1

A Product can have lots of things said about it, I'll call them Properties. It can have a brief description. But that description can be in multiple languages. Likewise, it can have multiple Prices, some which are specific to Customers. Given the following data:

Product:
  identifier: 123-ABC

   Price:
     value: $1.25
     currency: USD
     customer: Wal-Mart

   Price:
     value: $1.96
     currency: USD

   Description:
     short: "A Widget"
     language: EN

   Description:
     marketing: "Made from Space Age Polymers."
     language: EN

Does it make sense to use STI here, and make a generic set of models:

Product has_many Properties
Property has_many Attributes

Price < Property
Description < Property
Package < Property

Is this way too broad of a generalization in the data model? Should I just stick with regular models and their associated tables?

+3  A: 

No.

Seriously

No.

at least not in a SQL database.

If you want to use Cassandra or a NoSQL database, that's exactly how everything is stored.

Read my answer here and Read this

Think of a SQL Table with First Name, Last Name, and Birth date

Find all the LNAME = Page older than 30.

in one table it's

SELECT FNAME, LNAME, (SYSDATE - BDATE)/365 age FROM people WHERE LNAME = 'Page' and BDate < SYSDATE - 30*365

Now try it in an EAV

Post your answer.

Stephanie Page
I won't, but I bet it would have an EXISTS in it. I guess they all would. Thanks Steph ;-)
AKWF
But here's my real problem. There are LOTS of potential product attributes that are compound in nature. Like some value coupled with a language_code or a unit_of_measure. It seems crazy to have each of those as their own model or even as explicit attributes. The data standard I'm trying to handle has over possible attributes, some of them compound. But each product will only "care" about 50 or so.
AKWF
AK, That's a HUGELY important point... CARE, Care about 50. That means filter on or group on, etc. First, (i don't believe this because I'm a data addict) but why does your db have data no one cares about. Yes, I'd keep it to. And in those cases, you'd have to think about what you're going to do with it. If you're keeping it just to keep it, shove it in a CLOB or XMLType. Then when the 51st one becomes CARED for, add that column and do an update of the column from the XML Store.
Stephanie Page
Also, there's nothing wrong with vertical partitioning or PK-FK tables. You'd have one table with ID, Name, Category, etc... whatever is REALLY common. Then say you descriptions in 10 languages. So it's a 1-many between Product and description... create a description table with ID, LanguageCD, Description. etc... rationalize each property and how it fits in, how shared it is, is it really 1-1 or 1-many...
Stephanie Page
Now, one more thing. Is this used to populate a website or is this for something like an inventory system?
Stephanie Page
It's a combination management and display platform. What I have done today is broke out what I thought was very important as a stand-alone model, and put the data that is not common across all products in a sparse matrix. If something ever becomes "important", I can always extract that into a model.
AKWF
Your posts have been hugely helpful!
AKWF
by display do you mean reporting or displaying to an ecommerce site? Let's just say, if you want to make this really fast for ecommerce we'll need to discuss some further steps. I helped a friend build a very, very fast, online pet store.
Stephanie Page