Question

I have a table that has a bunch of fields. The fields can be broken into logical groups – like a job’s project manager info. The groupings themselves aren’t really entity candidates as they don’t and shouldn’t have their own PKs.

For now, to group them, the fields have prefixes (PmFirstName for example) but I’m considering breaking them out into multiple tables with 1:1 relations on the main table.

Is there anything I should watch out for when I do this? Is this just a poor choice?

I can see that maybe my queries will get more complicated with all the extra joins but that can be mitigated with views right? If we’re talking about a table with less than 100k records is this going to have a noticeable effect on performance?

Edit: I’ll justify the non-entity candidate thoughts a little further. This information is entered by our user base. They don’t know/care about each other. So its possible that the same user will submit the same ‘projectManager name’ or whatever which, at this point, wouldn’t be violating any constraint. Its for us to determine later on down the pipeline if we wanna correlate entries from separate users. If I were to give these things their own key they would grow at the same rate the main table grows – since they are essentially part of the same entity. At no pt is a user picking from a list of available ‘project managers’.

So, given the above, I don’t think they are entities. But maybe not – if you have further thoughts please post.

Answer 1

I don’t usually use 1 to 1 relations unless there is a specific performance reason for it. For example storing an infrequently used large text or BLOB type field in a separate table.

I would suspect that there is something else going on here though. In the example you give – PmFirstName – it seems like maybe there should be a single pm_id relating to a ‘ProjectManagers’ or ‘Employees’ table. Are you sure none of those groupings are really entity candidates?