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 > >
