Thanks Evgenii.
My next two questions are, assuming I go with option 1.1:
1) How do I define these nested addresses via query entities, assuming, I'd
use binaryobjects when inserting. There can be multiple primary addresses
and secondary addresses. E.g., {john,{primary-address:[addr1, addr2],
secondary-addess:[addr3, addr4, addr5]}}
2) Can I use SQL if I am filtering by person and then I want certain
information in the addresses? say I want all the primary addresses for
john., or I want the cities for the primary addresses for John.
thanks.
On Mon, May 11, 2020 at 4:56 PM Evgenii Zhuravlev <e.zhuravlev...@gmail.com>
wrote:
> Hi,
>
> The main question here is how you want to use this data. Do you use SQL?
>
> 1) It depends on the use case. If you plan to access only a person object
> without any filtering by addresses and you will always need the entire
> object, it makes sense to have one big object. But in this case, you won't
> be able to filter persons by addresses, since SQL doesn't work with
> collections. So, if you want to use SQL, it definitely makes sense to use
> the second approach.
>
> 2) Of course, if you already have unique ID for object, it makes sense to
> use it as a key, there is no need to generate an additional field for this.
>
> Evgenii
>
> пн, 11 мая 2020 г. в 09:20, narges saleh <snarges...@gmail.com>:
>
>> Hi All,
>>
>> I would appreciate your feedback, for the following, in terms of
>> performance for both inserts and queries.
>>
>> 1) Which one of these patterns is preferable for the table design?
>> A- Have a fat table/cache with nested objects, e.g. person table with a
>> hashmap of addresses.
>> B- Have person and address tables separate and just link them via foreign
>> keys.
>>
>> 2) Which one of these patterns is preferable for primary keys?
>> A- Have a UUID + affinity key as the primary key
>> B- Have the keys spelled out + affinity key. For example, assume person
>> table, combination of age and name uniquely identifies a person, so the key
>> will be person-name, person-age, and org-id.
>> If I have a associative table joining persons and addresses (if address
>> is a separate object), then in case B, I will have to include three fields
>> from person and the id from the address table, as opposed to case A, where
>> I will have UUID + orgid + address id. Would having one less field buy me
>> much, as opposed to having the overhead of creating UUIDs?
>>
>> thanks
>>
>>
