hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jignesh Patel <jigneshmpa...@gmail.com>
Subject Re: Fwd: data base design question
Date Fri, 13 Feb 2015 03:08:47 GMT
How about Option 1: Create an embedded entity of results and store it as
list object inside order table as one of the column field.

On Thu, Feb 12, 2015 at 6:59 PM, Wilm Schumacher <wilm.schumacher@gmail.com>
wrote:

> Hi,
>
> I think that Aloks solution and mine are kind of contrary.
>
> If you are able to make the one-to-many relationship by the key design
> in the result table then you wouldn't need the column family "results"
> in the order table. The "relation" would be intrinsic.
>
> If the key design in the results is somehow fixed by something else,
> than the column family solution would be necessary.
>
> But of course Aloks solution is somehow "cleaner", as you wouldn't need
> to save the relation to disk as it is intrinsic in the table. And you
> wouldn't produce problems with race conditions or the problem that the
> tables could end up in a erroneous state due to problems. E.g. deleting
> the result but leave the reference to it etc..
>
> And Aloks solution would be faster, as the other way you need to make a
> "Get" to get the rowkeys in the forst place, as Alok pointed out.
>
> Best wishes
>
> Wilm
>
> Am 12.02.2015 um 22:51 schrieb Alok Singh:
> > How are you going to access the results? Do you first lookup the order
> > and then the results? If so, you could do something like this:
> >
> > Table 1: Order
> > row_key => order_id
> > Column Family => order { columns: order.prop1, order.prop2....}
> >
> > Table 2: order_result
> > row_key => order_id:result_id
> > Column Family => result { columns: result.prop1, result.prop2....}
> >
> > To lookup a specific result, do a get(order_id + ":" + result_id) on
> > order_result.
> >
> > To get all results for an order, do a scan with startrow/endrow or a
> > use a prefix filter with order_id as the prefix.
> >
> > Alok
> >
> >
> > On Thu, Feb 12, 2015 at 1:23 PM, Wilm Schumacher
> > <wilm.schumacher@gmail.com> wrote:
> >> Am 12.02.2015 um 21:12 schrieb Dima Spivak:
> >>> Is there a better alternative than  above options for one to many
> >>> relationships?
> >> you could use a column family in table 2 for that.
> >>
> >> table 1
> >> result1 data:foo => bar
> >> result2 data:foo => baz
> >> result3 data:foo => bar
> >> result4 data:foo => baz
> >> ....
> >>
> >> table 2
> >> order1 data:metadata => foobar , result:1 => result1, result:2 =>
> result2
> >> order1 data:metadata => foobaz , result:1 => result3, result:2 =>
> >> result4 , ....
> >>
> >> Seems to be the best plan.
> >>
> >> Best wishes
> >>
> >> Wilm
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message