Database design question - repeating duplicate values [closed] - ruby-on-rails

Question

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 days ago.
Improve this question
The application I am working on has a hierarchy to the data tables it has, which is mostly straight forward. However, there is one field that is shared between most of the tables, that is acting like a secondary pk to the tables. Searching through google, this site and other places, I don't see any similar examples of this design. It appears that this design pattern is uncommon -- but does it's use create a problem that should be resolved?
Parent Table - Top level data object (ex: Product)
There are at least 10 sub tables (i.e., Manufacture, Materials, SalesRep, Vendor, etc...)
Each of the sub tables may or may not have other dependent tables.
The parent table, and some (but not all) of the dependent tables have a field called "Type" (saved as an integer). (ex: Physical, Electronic, Both)
The issue is, when selecting the data, the type_id is passed into all of the retrievals, for all of the tables. Doing so, allows for "Product" (ex, a "Book") to have one complete set of data (e.g., manufactures, materials, reps, vendors etc...) for one type of "Product" (ex: electronic book) and that same "Product" to have a completely different (or the same) set of data (e.g., manufactures, reps, etc...) for a different type of "Product" (ex: physical printed book).
Repeating the type_id through all of the tables duplicates the same data throughout the tables, resulting in essentially a two field pk for each record.
Currently:
--// Table: product
+------+-------------+----------------+
| id | date_issued | product_fields |
+------+-------------+----------------+
| 1 | 2010-08-20 | Book 1 |
| 2 | 2010-08-20 | Book 2 |
| 3 | 2010-08-20 | Book 3 |
+------+-------------+----------------+
--// Table: manufacturer
+------+------------+----------+-------------------+
| id | product_id | type_id | name |
+------+------------+----------+-------------------+
| 1 | 1 | 1 | Digital Printers |
+------+------------+----------+-------------------+
| 2 | 1 | 2 | Physical Printers |
+------+------------+----------+-------------------+
From what I can see, making "Type" relation a sub table under "Product", then having every other table be a dependent of product/type association is an alternative. However, to implement such a design change would require a great deal of refactoring both the database and code. While it is an alternative, is that the way others would do this?
Resulting in something like this:
--// Table: product
+------+-------------+----------------+
| id | date_issued | product_fields |
+------+-------------+----------------+
| 101 | 2010-08-20 | Book 1 |
| 102 | 2010-08-20 | Book 2 |
| 103 | 2010-08-20 | Book 3 |
+------+-------------+----------------+
--// Table: product_type_assoc
+------+-------------+-------------+
| id | product_id | type_id |
+------+-------------+-------------+
| 5 | 101 | 1 |
+------+-------------+-------------+
| 6 | 101 | 2 |
+------+-------------+-------------+
| 7 | 102 | 1 |
+------+-------------+-------------+
--// Table: manufacturer
+------+---------------------+-------------------+
| id | assoc_id | name |
+------+---------------------+-------------------+
| 1 | 5 | Digital Printers |
+------+---------------------+-------------------+
| 2 | 6 | Physical Printers |
+------+---------------------+-------------------+
An interim steps seems like having the current "type" in the product table, and passing that to the sub queries
Select from "Vendor" where "Product".id = 1 and "Type"_id = "Product".current_type
What do you think - Is this the preferred way, or is there a more commonly accepted design that does the same thing?