MV is a good option, but in case of RF, suppose If we are using RF =3 then
it will duplicate on 3*3 times which will be unwanted in case we insert a
lot of users.
But I think we can go with MV also.


On Fri, Jun 9, 2017 at 4:41 PM, Jacques-Henri Berthemet <
jacques-henri.berthe...@genesys.com> wrote:

> For query 2) you should have a second table, secondary index is usually
> never recommended. If you’re planning to use Cassandra 3.x you should take
> a look at materialized views (MVs):
>
> http://cassandra.apache.org/doc/latest/cql/mvs.html
>
> https://opencredo.com/everything-need-know-cassandra-materialized-views/
>
>
>
> I don’t have experience on MVs, I’m stuck on 2.2 for now.
>
>
>
> Regards,
>
> *--*
>
> *Jacques-Henri Berthemet*
>
>
>
> *From:* @Nandan@ [mailto:nandanpriyadarshi...@gmail.com]
> *Sent:* vendredi 9 juin 2017 10:27
> *To:* Jacques-Henri Berthemet <jacques-henri.berthe...@genesys.com>
> *Cc:* user@cassandra.apache.org
> *Subject:* Re: Reg:- Data Modelling For Hierarchy Data
>
>
>
> Hi,
>
> Yes, I am following with single Users table.
>
> Suppose my query patterns are:-
>
> 1) Select user by email.
>
> 2) Select user by user_type
>
> 1st query pattern will satisfy the Users table, but in the case of second
> query pattern, either have to go with another table like user_by_type or I
> have to create secondary index on user_type by which client will able to
> access Only Buyer or Seller Records.
>
>
>
> Please suggest the best way.
>
> Best Regards.
>
> Nandan
>
>
>
> On Fri, Jun 9, 2017 at 3:59 PM, Jacques-Henri Berthemet <
> jacques-henri.berthe...@genesys.com> wrote:
>
> Hi,
>
>
>
> According to your model a use can only be of one type, so I’d go with a
> very simple model with a single table:
>
>
>
> string email (PK), string user_type, map<string, string> attributes
>
>
>
> user_type can be Buyer, Master_Seller, Slave_Seller and all other columns
> go into attribute map as long as all of them don’t exceed 64k, but you
> could create dedicate columns for all attributes that you know will always
> be there.
>
>
>
> *--*
>
> *Jacques-Henri Berthemet*
>
>
>
> *From:* @Nandan@ [mailto:nandanpriyadarshi...@gmail.com]
> *Sent:* vendredi 9 juin 2017 03:14
> *To:* user@cassandra.apache.org
> *Subject:* Reg:- Data Modelling For Hierarchy Data
>
>
>
> Hi,
>
>
>
> I am working on Music database where we have multiple order of users of
> our portal. Different category of users is having some common attributes
> but some different attributes based on their registration.
>
> This becomes a hierarchy pattern. I am attaching one sample hierarchy
> pattern of User Module which is somehow part of my current data modeling.
>
>
>
> *There are few conditions:-*
>
> *1) email id should be unique. i.e If some user registered with one email
> id then that particular user can't able to register as another user. *
>
> *2) Some type of users having 20-30 columns as in their registration. such
> as company,address,email,first_name,join_date etc..*
>
>
>
> *Query pattern is like:-*
>
> *1) select user by email*
>
>
>
> Please suggest me how to do data modeling for these type of
> hierarchy data.
>
> Should I create a seperate table for the seperate type of users or should
> I go with single user table?
>
> As we have unique email id condition, so should I go with email id as a
> primary key or user_id UUID will be the best choice.
>
>
>
>
>
>
>
> Best regards,
>
> Nandan Priyadarshi
>
>
>

Reply via email to