0

Let us say I want to store on a database a userID, their nationality and if they are from the UK their UK passport number.

I could model this by having one table with userID as primary key, nationality as an attribute and the Uk passport number as an attribute , which exists only when the nationality is UK.

enter image description here

As an alternative I could have two tables, one with the userID as the primary key and the nationality as an attribute and a different table with UserId as the primary key and the Uk passport number as an attribute .

enter image description here

Is there a difference between these two designs given I use a document oriented schema-less database ? Both approaches have a O(1) query complexity and the only difference I can see is that on the first one if you want to retrieve the passport number you have to fetch the whole object. Is there another reason I should prefer the second approach which also seems a bit more complex to develop ?

I am interested in arguments on maintainability and scaling as well .

1
  • I don't think there is enough context to say for certain, but I would err on the side of less complexity (KISS). How would the "schema" evolve over time? Would changes influence both tables? If so, then keep them together. If not, and each concept evolves independently, keep them separate. Fetching the whole object is not an issue, until it becomes one for some reason, so don't overcomplicate your model just in case. Premature optimization will hurt more than it will bring good.
    – Blaž Mrak
    Jun 14, 2021 at 21:16

1 Answer 1

1

Semantically, in the current state of the model, there is no real difference. On the non-functional side, one may get the ability of placing individual access rights to the UKPassport table (in an easier way), but one should check if such a requirement really has to be expected.

Something which may make a difference is potential evolvement: as soon as you want to add further passport related attributes, which are not attributes of a user (like expiration date, color, size etc), it makes sense to model the passport as an entity of its own. However, it may be early enough to refactor the model at the time when these requirements "arrive", depending on how easy it is in your development process to change a data model at a later point in time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.