I will follow exactly this solution - thanks :) On Fri, Nov 18, 2011 at 9:53 PM, David Jeske <[email protected]> wrote:
> On Thu, Nov 17, 2011 at 1:08 PM, Maciej Miklas > <[email protected]>wrote: > >> A) Skinny rows >> - row key contains login name - this is the main search criteria >> - login data is replicated - each possible login is stored as single row >> which contains all user data - 10 logins for > > single customer create 10 rows, where each row has different key and the >> same content >> > > To me this seems reasonable. Remember, because of your replication of the > datavalues you will want a quick way to find all the logins for a given ID, > so you will also want to store a separate dataset like: > > 1122 { > [email protected] =1 (where the login is a column key) > [email protected] =1 > } > > When you do an update, you'll need to fetch the entire row for the > user-id, and then update all copies of the data. THis can create problems, > if the data is out of sync (which it will be at certain times because of > eventual consistency, and might be if something bad happens). > > ...the other option, of course, is to make a login-name indirection. You > would have only one copy of the user-data stored by ID, and then you would > store a separate mapping from login-name-to-ID. Of course this would > require two roundtrips to get the user information from login-id, which is > something I know you said you didn't want to do. > > >
