Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 54172 invoked from network); 28 Jun 2010 02:38:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Jun 2010 02:38:51 -0000 Received: (qmail 90222 invoked by uid 500); 28 Jun 2010 02:38:50 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 90059 invoked by uid 500); 28 Jun 2010 02:38:48 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 90051 invoked by uid 99); 28 Jun 2010 02:38:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jun 2010 02:38:47 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=EXTRA_MPART_TYPE,HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [117.120.16.147] (HELO mail62.messagelabs.com) (117.120.16.147) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jun 2010 02:38:38 +0000 X-VirusChecked: Checked X-Env-Sender: Anthony.Ikeda@cardlink.com.au X-Msg-Ref: server-6.tower-62.messagelabs.com!1277692570!2874986!1 X-StarScan-Version: 6.2.4; banners=cardlink.com.au,-,- X-Originating-IP: [203.36.58.163] Received: (qmail 20477 invoked from network); 28 Jun 2010 02:36:10 -0000 Received: from unknown (HELO rmail.5f55.cardlink.local) (203.36.58.163) by server-6.tower-62.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2010 02:36:10 -0000 Received: from r-exchange.cardlink.local (r-exchange.cardlink.local [10.3.3.3]) by rmail.5f55.cardlink.local (8.13.5.20060308/8.13.4) with ESMTP id o5S2a9b0024098 for ; Mon, 28 Jun 2010 12:36:09 +1000 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CB166A.AA752A03"; type="multipart/alternative" Subject: Understanding SuperColumns Date: Mon, 28 Jun 2010 12:36:05 +1000 Message-ID: <590CDE7A083C4142AF05E96F2FB543BC973F79@r-exchange.cardlink.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Understanding SuperColumns Thread-Index: AcsWaqhVQAE+zz2uTGKaJQXHu0WoJA== From: "Anthony Ikeda" To: X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01CB166A.AA752A03 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB166A.AA752A03" ------_=_NextPart_002_01CB166A.AA752A03 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I seem to be scratching my head about how to model Super Columns properly and how they relate to a 1 to many kind of relationship. =20 For example: =20 UserAccounts =3D { "PB12345": { firstname: "Paul", surname: "Brown", address: {street: "Main St", suburb: "Springfield", state: "NY"} } } =20 Here I'm using address as a super column based on some of the examples I've come across. What if Paul has multiple addresses or if an address belonged to more than one person? Is the following still valid? =20 UserAccounts =3D { "PB12345" : { firstname: "Paul", surname: "Brown" }, "SB12345": { firstname: "Sue", surname: "Brown" } } =20 Addresses =3D { "address1": { street: "Main St", suburb: "Springfield", state: "NY", owners: { "PB12345": {createdDate: "20100626"}, "SB12345": {createdDate: "20100522"} } }, =20 "address2": { street: "Berry St", suburb: "New York",=20 state: "NY", owners: { "PB12345": {moveInDate: "20100421"} } }, "address3": { street: "5th Avenue", suburb: "Springfield",=20 state: "NY" } } =20 AddressesByType =3D { "home": { address1: { street: "Main St", suburb: "Springfield", state: "NY", owner=3D"PB12345"} }, "work": { address2: {street: "Berry St", suburb: "New York", state: "NY", owner=3D"PB12345"}, address3: {street: "5th Avenue", suburb: "Springfield", state: "NY"} } } =20 AddressByCity =3D { "New York": { "address2": {createdDate: "01/01/1937"} }, "Springfield": { "address1": {createdDate: "12/05/1940"}, "address3": {createdDate: "12/12/1880"} } } =20 I understand that: 1. There is a lack of relationships in modelling with NoSQL systems between entities 2. Data is represented in a way that you need to query it (e.g. I need a model that represents all addresses by type, all addresses by city, etc) =20 But to what degree do I end up tearing the data apart? =20 Say my query is: Get all Work addresses in New York and the address owner. Steps to get the data would be: =20 1. Find out which addresses are classified as "Type=3DWork" and get the primary key of the super column (returns [AddressByType][work][address2] and [AddressByType][work] [address3]) 2. Then get all the addresses located in "New York" (returns [AddressByCity][New York][address2]) 3. Then get "owner" field from my records returned in Step 1 ([AddressByType][work][address2][owner=3D"PB12345"], address3 is abandoned) 4. Then retrieve the User details and Address details using "address2" and "PB12345" using a kind of union...I think. =20 Am I over complicating this? =20 =20 Anthony Ikeda Java Analyst/Programmer Cardlink Services Limited Level 4, 3 Rider Boulevard Rhodes NSW 2138 =20 Web: www.cardlink.com.au | Tel: + 61 2 9646 9221 | Fax: + 61 2 9646 9283 =20 =20 ********************************************************************** This e-mail message and any attachments are intended only for the use of t= he addressee(s) named above and may contain information that is privileged= and confidential. If you are not the intended recipient, any display, dis= semination, distribution, or copying is strictly prohibited. If you beli= eve you have received this e-mail message in error, please immediately not= ify the sender by replying to this e-mail message or by telephone to (02) = 9646 9222. Please delete the email and any attachments and do not retain t= he email or any attachments in any form. ********************************************************************** ------_=_NextPart_002_01CB166A.AA752A03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

I seem to be scratching my head about how to model Su= per Columns properly and how they relate to a 1 to many kind of relationship.<= o:p>

 

For example:

 

UserAccounts =3D {

         = ;       “PB12345”: {

first= name: “Paul”,

surna= me: “Brown”,

addre= ss: {street: “Main St”, suburb: “Springfield”, state: “NY= ”}

}

}

 

Here I’m using address as a super column based = on some of the examples I’ve come across. What if Paul has multiple addresse= s or if an address belonged to more than one person? Is the following still val= id?

 

UserAccounts =3D {

         = ;       “PB12345” : {

first= name: “Paul”,

surna= me: “Brown”

         = ;       },

         = ;       “SB12345”: {

         = ;            &= nbsp;          firstname: “Sue”,

         = ;            &= nbsp;          surname: “Brown”

         = ;       }

}

 

Addresses =3D {

         = ;       “address1”: {

stree= t: “Main St”,

suburb: “Springfie= ld”,

state: “NY”,=

owners: {

=

    =              &= #8220;PB12345”: {createdDate: “20100626”},

    =             “= SB12345”: {createdDate: “20100522”}

}

 },

         = ;       “address2”: {

stree= t: “Berry St”,

subur= b: “New York”,

state= : “NY”,

owner= s: {

 = ;            &= nbsp;  “PB12345”: {moveInDate: “20100421”}

}

},

“address3”: = {

stree= t: “5th Avenue”,

subur= b: “Springfield”,

state= : “NY”

}

}

 

AddressesByType =3D {

         = ;       “home”: {

         = ;             =           address1: { street: “Main St”, suburb: “Springfield”, state:= “NY”, owner=3D”PB12345”}

         = ;       },

         = ;       “work”: {

addre= ss2: {street: “Berry St”, suburb: “New York”, state: “NY&#= 8221;, owner=3D”PB12345”},

addre= ss3: {street: “5th Avenue”, suburb: “Springfield&#= 8221;, state: “NY”}

         = ;       }

}

 

AddressByCity =3D {

         = ;       “New York”: {

         = ;            &= nbsp;          “address= 2”: {createdDate: ”01/01/1937”}

         = ;       },

“Springfield”= ;: {

    =             “= address1”: {createdDate: “12/05/1940”},

         = ;            &= nbsp;          “address= 3”: {createdDate: “12/12/1880”}

}

}

 

I understand that:

1.&= nbsp;      There is a lack of relationships in modelling=20wi= th NoSQL systems between entities

2.&= nbsp;      Data is represented in a way that you need to quer= y it (e.g. I need a model that represents all addresses by type, all addresses = by city, etc)

 

But to what degree do I end up tearing the data apart= ?

 

Say my query is: Get all Work addresses in New York a= nd the address owner. Steps to get the data would be:

 

1.&= nbsp;      Find out which addresses are classified as “= Type=3DWork” and get the primary key of the super column (returns [AddressByType][work]= [address2] and [AddressByType][work] [address3])

2.&= nbsp;      Then get all the addresses located in “New Y= ork” (returns [AddressByCity][New York][address2])

3.&= nbsp;      Then get “owner” field from my records= returned in Step 1 ([AddressByType][work][address2][owner=3D“PB12345= ”], address3 is abandoned)

4.&= nbsp;      Then retrieve the User details and Address details= using “address2” and “PB12345” using a kind of union...I think.

 

Am I over complicating this?

 

 

Anthony Ikeda

Java Analyst/Programmer=

Cardlink Services Limited

Level 4, 3 Rider Boulevard

Rhodes NSW 2138

 

Web: www.cardlink.com.au | Tel: + 61= 2 9646 9221 | Fax: + 61 2 9646 9283

3D"logo_cardlink1"

 


**********************************************************************
= This e-mail message and any attachments are intended only for the use of t= he addressee(s) named above and may contain information that is privileged= and confidential. If you are not the intended recipient, any display, dis= semination, distribution, or copying is strictly prohibited. If you beli= eve you have received this e-mail message in error, please immediately not= ify the sender by replying to this e-mail message or by telephone to (02) = 9646 9222. Please delete the email and any attachments and do not retain t= he email or any attachments in any form.
**********************************************************************
= ------_=_NextPart_002_01CB166A.AA752A03-- ------_=_NextPart_001_01CB166A.AA752A03 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhmwBsAOYAAHcAAPzezYqIiXRzc8C+v40+JO2KZOHg4NYAGqWkpf////fRu+2rirxrTdOO bt0rJuNaPLwAEttEL359fejn5/707szMzLt8X6+urvGjfuXCrpkAANetlbBDKsWNcZmZmeZsSff3 94EfDeS3n7cAD8tePeh7Vu6XcdjX2O/v76RUONqdfv3p3vDd0dR7WOXLu4QAAN+0nJmZmbi2t8YA FrlgQbcfGtVCLZInE5pEKfjHrfa8nfft58uBX3wcCpgTD8ubgd2VdOG+quBpRtaiiJpPNOy0l/PX x4wAAM4AF+u9pOGDX/fOte/e1tqmi30AAKNcQdNTN5NBJ8+Ud95zUqhMMPnTvd5KMfSwjsMAFN6c c9uwmPC4mpkAAJ9HLOGPavjbytaljHsHAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAQUAP8ALAAAAACbAGwAAAf/gAqCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f 4OHi4+Tl5ufo6err7O3u7/Dx8rNWBvOkFScIIPejBhAIrvQbBQLLg4GhTvCzgvDTDgQBGn7SgeCE RE8BHkiocJFTRgQMO2r6aFFkpo8QOJq89PFBxJWWrDxAgEAHTEsPaWK5WSkDTQT2eEqqYOJnUKGH FijREqRp0yMBrhhFSqgClyVRsmSJwJUECRtKsPwEOmIE1R1UkqilwZYG1xIu/8CAGHvCwYa7NZzw MFkhgwQEatVG+WIEzCCfY3coWNGjw90NPxpokNh35s8bDFgU0iH1p8tCPEY0+IEESRUiAzmPHbLA kJW5Y0GoRBSjAQwYOFDHIxo7JKEdAMc+2NmIxxQcT7wIeSfTM/FBAU5Yjq050hYvAFTsXYeYJoSX Cqyc6Dw2oM1KQnKI8ZCuggHhOzL8Ky88gyYOIqS0MFchOP3/NF2BxWyaXOADB+T0ByCAICgGSgtF QLHdNwouONYVJ1Q3CgcF7OdNhRYWBJ4pPEDxQjcglneFCRn41kgIB8R4gAIsWGHjiJAAgWAhAdho BYHNZADCkBkUaWMlBwyg5P8HCnRnnyEsFFlkIi9MKAhsIA1DAQEffDDABF0SQIEoSS6pAJZPFpIT AhBAMh2OvBzgpZJ01mlBKATQicGZPzlYSHf8PDJWMDPUaSidKeBJJwEKTOfiIPrQdBQjFQz6CwaG TpAAAQRg4GUComCq5J1jPSpIfEY+YsVPbfpSKJ0C3FlIComGMucAB1T6Eyer0hRonHV+EMIiKWAg gJIJzIhCl0zO0CWoFjB7ZwhcLnnnrQf0ShMiCg0ZwA5DghBAX3M9YMJ5TU4lCFHhpinLrQIMq0ie h0Zr5gRLijoqCvgaqu8AIWgr0CFjsfAeTR+VV5KT6/qXEi0U2LkIvYcGq0D/xV+WiTGdCojlKyKD YjldeQwdjMBOID5MC8UCLBIxnRPMQEAChiYQAsYJHKsnAa/Cmu7HhgTgmQL+0cRi0fZg+aN/BgAZ C81K7qkI1APEOwjFAxCgccaCWFDnmIJszaTJ7g6iLT/C+YYlP/7pwDQutzKaSAp1zjjIzYtuDbYC OmddyK1MonkIRR+XSgjh+yhwobq3xK2I10q2/DedB1DMpCB0I1oIxYxi6Sch3Z0gNE0HHf4T2vRN asutM8yrpyHYcj6IxpITIrvhhjh59p8/if7fc43TeTkishfS7wDFLjoICsIbQjUKiv8EpwJF0bQD 4r8KojuA08uCtd2HUNw6/yEvK6kAtoNAPsDwgxx/AAuWGqI0w4RUfzLiEkynsi3lf7n35s0jBNUG cD7Kza5O8ura17SFAESQxwr0G8T8fpIBxFUkFwOcAAESqIAUWEB9A5CVAnq2vovRKYGZi9ryDKUA xLXKECH7CboE8UCG2a8muAjB8YTXpX7xK1gf6JuZ6jQ5WHXpUD9bEPx2pbRCxJAmNqkAeR7gNFlQ 4FYY4xTGjjeD8k2gEFur0/GY1B0AaatN5NGQIJ6YpfDEJhfU2qGhWkdCZDFPSVoLICEsIMcPlI9J N6TPA3YXP0EITAHkAU+kdLKLynkqTBaoVQdntqkxwShGKbjkAf53Nwt4ijIA0FOAjMbUIx+Z8kYV 8FFETFmIVN4oPD6qyimpQsta2vKWuMylLnfJy1768pfANEcgAAA7 ------_=_NextPart_001_01CB166A.AA752A03--