 <p><strong>Option 1:</strong><br> I think that from the select efficiency point of view, option 1 might give you the best result, using a filtered index on the <code>userId</code> column in the <code>UserScan</code> table.</p> <p><strong>Option 2:</strong><br> Your second option is probably the worst option since it means you will have two almost identical table structures in your database, and that's a bad design.</p> <p><strong>Option 3:</strong><br> On the academic level, option 3 is the way to go. Nullable columns are frowned upon in the relational model. To prevent the <code>UserScanEvent</code> table from creating a many to many relationship between scans and persons, add a unique constraint on the <code>scanId</code> column. this way, each scan in this table can only be associated with a single person.</p> <p><strong>To sum up:</strong><br> Having said all that, Select efficiency is a tricky thing to predict. My hunch tells me that option 1, while might not be the best fit to the relational model, will enable faster select executes then option 3, but as Jorge Campos wrote in his comment, it is merely my opinion, it's not something I can say for sure.</p>