Question

I’m storing test data that may include times in various formats that are slightly different (TAI, UTC, GPS, etc). I’m not sure I want to force the times to be converted to an arbitrary consistent format before being input (or maybe that’s the best way?), but assuming I can keep the flexibility, I plan to use a reference table (lookup table) of time types like so:

ref_time_types
--------------
id (PK)
desc (UTC, GPS, TAI, etc)

and I’ll also have a table to store the actual times:

tbl_time
-------------
id (PK)
ref_time_types.id (FK)
seconds
year
.
.
.

Should I establish a bidirectional relationship between these, or a unidirectional many-to-one from tbl_time to ref_time_types? I can’t think of any reason I would want to find all the UTC times, for example. Is that the guiding principle on whether to create a bidirectional relationship? Is there any best practice when it comes to relationships for reference tables?

Answer 1

Do you actually need to preserve the format?

1. If no, then don’t store it in the database. Database is for storing data, it shouldn’t care about how the data is represented in the UI. So, I’d recommend you handle the input however you want in the UI (if that means multiple formats, so be it), but convert it to consistent format before storing it to the database and get rid of the ref_time_types altogether.
2. If yes, then go ahead and store the format as well, but I’d still use the consistent representation of the date/time itself since it would require less conversions when querying (you just need to convert the input criteria for the query, instead of all the rows that don’t match the desired format).

Also, do use date/time type supported by your DBMS – I don’t see a particular reason to split various date/time components to separate fields unless you actually want to query on these individual components (and want to index them).

Should I establish a bidirectional relationship between these, or a unidirectional many-to-one from tbl_time to ref_time_types?

As discussed above, you won’t need any relationship in the first case (since there is only one table). A relationship would be many-to-1 the second case.