yosiasz, thanks for your code and advice. It might just work. It looks interesting.
I have to look at it closely.
ScottPletcher, thanks for your answer, that makes sense. But it does affect my query though (but that is not a problem it can be done easily) if in one table has different dates or just one date. I have to find the other date for the other category, example depicted.
How about this situation. Only if you can picture this.
I have a list of items, lets say 2000 of them. However in this list of items, some items gets updated monthly and some don't. The one that does I make it appear in this table in the month that it is updated. So lets say Feb 2018, out of 2000 items, 500 gets updated. In this Feb 2018 month 500 items gets tag, if someone was to do a query for Feb 2018 they don't see the whole list of 2000 items, they only see the 500. This is the table design base on convenience of import, less work and no redundancy.
However we need to see the complete list for every time someone does a query for a month even if the item is not updated (the reason is because is useful for application development purpose). My answer to the table design was to create a store procedure that would update a new table that would have the complete list. For example we are in December 208, the store procedure will go though all 2000 items and then find any items it can for December 2018 and put it in the new table, whatever it can't find it will search for the next last date of the item and put it in the new table and then it will do so for the next date that an item is updated until the complete 2000 item are listed. It will do this until there is no more updated date. Hope I make sense.
Do you think this is a good database design or should we just import all 2000 items even though some of it's item is not updated (this I think is redundant work but is easier on the store procedure and query if we ever need the data to create applications).
Please advise !