Open kylecannon opened 11 years ago
Only thing I can think of is its going to be another join. Let me think more about it — Sent from Mailbox for iPhone
On Fri, Apr 26, 2013 at 7:08 PM, Josh Ribakoff notifications@github.com wrote:
What do you think about storing this in an association table instead of adding a store_id column to the fitments table? A fitment could apply to one or more stores. We could also omit the association table when deploying the VF library in a non e-commerce environment
Reply to this email directly or view it on GitHub: https://github.com/vehiclefits/Vehicle-Fits-Magento/issues/16#issuecomment-17108594
What's the problem with that, performance concern? Premature optimization possibly. Can we specify what our desired performance is? Who cares if it uses a billion joins as long as its fast at the end of the day? Basically it shouldn't matter if its getting the data from the database using a carrier pigeon for all I care, as long as it performs the operation in X number of milliseconds
Implementation aside, what is the goal here? To associate a schema with one or more stores? Or to associate a fitment with one or more stores?
Let's say the schema on both stores are "year,make,model".. do we create two schemas and import the fitment into both schemas? Or do we have on schema that we import a fitment into once, and it associates it to multiple stores?
Actually, after being more coherent, I believe doing a separate tables for the association to the store_id is a good idea. A great way to implement this would be able to have the import csv functionality to be able to associate fitments with the store. Example:
sku | year_start | year_end | make | model | store_id |
---|---|---|---|---|---|
sku1 | 2000 | 2005 | Toyota | Camry | 1 |
sku2 | 2000 | 2005 | Ford | F-150 | 2 |
sku3 | 2000 | 2003 | Toyota | Landcruiser | 1,2 |
Now, if the store_id is left blank upon importing, it defaults to store_id 1.
To implement this, we would have to move all the import functionality down to the core library and extend it into the magento module to add just the store support. This would also need to happen for the schema creation as well.
The multi store support could be useful outside of magento too, but should definitely be optional. On Apr 27, 2013 9:21 PM, "Kyle Cannon" notifications@github.com wrote:
Actually, after being more coherent, I believe doing a separate tables for the association to the store_id is a good idea. A great way to implement this would be able to have the import csv functionality to be able to associate fitments with the store. Example: sku year_start year_end make model store_id sku1 2000 2005 Toyota Camry 1 sku2 2000 2005 Ford F-150 2 sku3 2000 2003 Toyota Landcruiser 1,2
Now, if the store_id is left blank upon importing, it defaults to store_id 1.
To implement this, we would have to move all the import functionality down to the core library and extend it into the magento module to add just the store support. This would also need to happen for the schema creation as well.
— Reply to this email directly or view it on GitHubhttps://github.com/vehiclefits/Vehicle-Fits-Magento/issues/16#issuecomment-17126475 .
Well multi store support would have to be module dependent so it would have to be made for each web store we decide to make it for. We can't just have it in the core in my opinion.
What about other carts that have multi store support? Store id is just as generic as product id. On Apr 27, 2013 9:31 PM, "Kyle Cannon" notifications@github.com wrote:
Well multi store support would have to be module dependent so it would have to be made for each web store we decide to make it for. We can't just have it in the core in my opinion.
— Reply to this email directly or view it on GitHubhttps://github.com/vehiclefits/Vehicle-Fits-Magento/issues/16#issuecomment-17126575 .
What do you think about storing this in an association table instead of adding a store_id column to the fitments table? A fitment could apply to one or more stores. We could also omit the association table when deploying the VF library in a non e-commerce environment