LOL... Ian wrote: "But, something just occurred to me: just because your physical implementation (HBase) doesn't support normalized entities and relationships doesn't mean your *problem* doesn't have entities and relationships. :) An Author is one entity, a Title is another, and a Genre is a third. Understanding how they interact is a prerequisite for translating into a physical model that works well in HBase. (ERD modeling is not categorically the only way to understand that, but I've yet to hear a credible alternative that doesn't boil down to either ERD or "do it in your head"). "
You can have entities, except that they are not coupled. If you have a common key, then you may have a use for column families, it just depends on your data and how you access your data. Its not rocket science, but its a non-trivial matter. Not doing it right may mean that you are not going to get the most out of your system. On Jul 5, 2013, at 1:26 PM, Ian Varley <[email protected]> wrote: > But, something just occurred to me: just because your physical implementation > (HBase) doesn't support normalized entities and relationships doesn't mean > your *problem* doesn't have entities and relationships. :) An Author is one > entity, a Title is another, and a Genre is a third. Understanding how they > interact is a prerequisite for translating into a physical model that works > well in HBase. (ERD modeling is not categorically the only way to understand > that, but I've yet to hear a credible alternative that doesn't boil down to > either ERD or "do it in your head").
