> From: [email protected]
> To: [email protected]
> Subject: RE: Schema design, one-to-many question
> Date: Tue, 30 Nov 2010 16:11:14 +0000
>
> I'm not sure I agree that "you can not think of relationships".
>
> There is in fact a one-to-many relationship in the described schema,
> regardless of the database you are modeling it in. I'm not sure why you
> would not want to think about these relations?
>
> And a row being userid with a family containing a column per order seems like
> a very legitimate way to store a one-to-many relationship. However it's not
> exactly as you've described (primary key == foreign key). One primary key is
> userid, the other is orderid (or if orderid is only unique per user, the
> second primary key is userid+orderid). Relational thinking would be three
> tables (users, orders, userorders), HBase thinking would be one table keyed
> on user.
>
> What you need to "drop" from the relational model is the idea of breaking
> these things up into different tables to join them later. With
> column-orientation, you can have the user as the row and stuff all of his
> relations into that same row.
>
> JG
Sigh. I knew this would cause trouble... :-)
The point I'm trying to make is that you need to break away from thinking in
terms of everything as a 3rd Normal form relational model.
That's not to say that there aren't relationships between tables, or the
organization, but that you're not following relational modeling.
In a hierarchial ?sp? model, you do have relationships, but not necessarily in
terms of a relational model.
A simple example... in an order, you have a section of order detail (sku,
description, qty, unit price, order amt). In a relational model, the order
detail is a separate table.
In a hierarchy, the order detail is actually a column of the order row. (Like I
said, look at Dick Pick's stuff.)
Note: There's more than one way to skin the cat... which means that you can
have two models that are both correct. The key is how you access the data.
In this example, you're going to hit your customer table first, then you're
going to hit your order table. (Unless you're letting anyone who knows an order
number look it up without authenticating the user/customer ...) ;-)
Sorry but its hard to chunk out a design in quick e-mail blurbs.
HTH
-Mike
