My database stores version numbers; however, they come in two formats: major.minor.build (e.g. 8.2.0, 12.0.1) and dates (e.g. YY-MM-DD). I had thought of two solutions:
+---+---+-----+-----------+ +-----+-----+-----+-----+ +-----+--------+
|...|...|id |versionType| |id |major|minor|build| |id |date |
|---+---+-----+-----------| |-----+-----+-----+-----| |-----+--------|
|...|...|12345|0 | |12345|0 |1 |2 | |21432|12-04-05|
|---+---+-----+-----------| +-----+-----+-----+-----+ +-----+--------+
|...|...|21432|1 |
+---+---+-----+-----------+
or
+---+---+-----+-----+-----+-----+--------+
|...|...|id |major|minor|build|date |
|---+---+-----+-----+-----+-----+--------|
|...|...|12345|0 |1 |2 |null |
|---+---+-----+-----+-----+-----+--------+
|...|...|21432|null |null |null |12-04-05|
+---+---+-----+-----+-----+-----+--------+
Neither of these look particularly efficient: the first requires a join across two tables just to get a version number, while the second wastes twice as much space per version entry compared to the first. Alternatively, I could just store the value in some amount of bits in a column then interpret that on the client side, but I’m hoping that there’s some standard practice for this situation that I’ve overlooked.
Is there a proper way to store two different types of data for the same ‘column’ in a relational database?
I don’t think there’s a silver bullet here. If you are adamant about having a single column you could just naively slapping them both into a CHAR(10), though this has its own issues (e.g., invalid dates, or malformed build number strings, etc).
I think the key question is really what sort of queries do you envision running, and how many rows do you expect to have?
I’d let the anticipated query need drive the DB design.