Note: I'm not saying that B is the best solution, but out of A and B, I would pick B.
I think one of the questions you're trying to ask is about localization. My thought, and a lot of areas seem to agree, localization is best left at the database level. In java we use Resource bundles that have ISO language codes attached to them to load different Strings for display into the class.
The main reason I picked B over A is that you don't have any way of versioning the widget itself in either case, which makes A look even worse. Even so, making it date based isn't always the best solution. What happens if the price of widgets changes twice in one day? Or you get a bunch of mutant widgets that are 2x2 at noon, and 3x2 at 2pm and 5x1 at 4:30pm?
Obviously if there are going to be 50 different attributes of a widget, Method B won't work at all. It will be a management nightmare.
Thank you for the continued input, chaz.
a) I researched "database localization" and couldn't find information relative to the scenarios that I presented. It would be greatly appreciated if you could provide for me a link, or some more information on the topic.
b) We are concerned only with changes or additions made on a particular date.
c) Considering my aforementioned concerns about data type conflicts and the possibility of wanting to further describe a piece of data, I'm surprised that method A would even be considered as an option. Sure, I'd have to build those 50 tables and establish the relationships, and that obviously would take more initial time. Queries could include many joins. But if I want to designate a decimal data type for values to be stored in the "PRICES" table, and designate an alphanumeric data type for values to be stored in the "DIMENSIONS" table, then I can; method A would force me to store prices and dimensions as one data type. Furthermore, if I want to further describe prices as "USD" or "EUR", then method B would simply require adding a field to "PRICES" containing the primary key from a "PRICETYPES" table. Similarly, if I want to further describe dimensions as "inches" or "feet", then method B would simply require adding a field to "DIMENSIONS" that would store the primary key from a "DIMENSIONTYPES" table. I don't have this expandability using method A.
I hope I'm being somewhat clear as to what the boggle is. Thanks again for taking the time to help.