I have a business requirement that poses an interesting design question. My company makes dyes that detect leaks in fluid systems. All chemicals require a SDS (Safety Data Sheet) that specifies safety information about that chemical. The SDS is produced by specialized software, so I need to do is keep track of the link to where it is stored on our drive. The typical use of this information is to print out all the SDS's required for a specific order.
The complication is that sometimes we sell products which are kits containing multiple dyes, each with its own SDS. So the question is what is the best way to keep track of this.
Approach #1 Create a double-keyed table called PRODUCT_COMPONENT which relates the product numbers with the individual components for the kits only. To print the SDS I would need to combine 2 queries, one for the kits and another for non-kit products
Approach #2 Create a double-keyed table called PRODUCT_COMPONENT for all products, kits or not. If the product is not a kit, the value of COMPONENT will be the same the value of PRODUCT. To print the SDS's I would have query that links PRODUCT_COMPONENT with the table that stores information fields about our products,
Approach #1 has less data entry.
Approach #2 avoids need for left joins and iif's. It also easier to validate as I can easily test that all saleable products have at least 1 entry in PRODUCT_COMPONENT.
Which approach is better? I am leaning towards approach #2 as in most cases I can identify automatically non-kits by their description and populate PRODUCT_COMPONENT.
Related
We are about to begin working on an addition to Magento 1.14.2 EE that will allow us to merchandise and sort products within categories at a store level. currently we do this by having 3 entirely separate root category trees, our editors are finding this cumbersome, and our indexing takes 3x the time it should take to reindex a single tree.
The plan is to add a store_id column to the catalog_category_product table which currently stores the product_id, category_id and products position within the category in question.
So my questions are fairly general at this point, has anyone attempted this previously and are there any obvious pitfalls that we are likely to encounter as a result of attempting this? The solution to us seems fairly obvious yet it hasn't been implemented yet by Magento, surely this is a piece of functionality that would be useful for any company that has a presence in multiple countries.
I'm about to rebuild an e commerce website with a mid sized database of about 40,000 product.
One of the main reasons we are putting the old system to retire is the categorization mechanism.
We are looking for something that will allow us to place an item under multiple categories, or even better having no fixed category at all and we can classify products by putting descriptive labels on them and the front user can search for the products by using these labels. (I don't even sure that this can be done from a programming point of view).
It will be helpful to know what this model is called, whether it was implemented before? and even better if you can refer me to ready solutions.
Here's the setup (using a made-up scenario), but applicable to my real situation:
For the purposes of this explanation, let's say that i design T-shirts (Let's call them ShirtA, shirtB, shirtC). Rather than selling them myself, i have several vendors that sell the product for me (we'll call them Vendors X, Y, and Z).
I have a table in my Joomla database for the vendors, and a table for the t-shirts.
When customers are buying from this vendor, they will visit my site and based on the ID url variable, will display a different vendor's page.
Each vendor can choose to sell all of my t-shirts, or only some of them. Additionally, the vendor can override the price that i have set in the t-shirt table, with their own.
In the admin section of the component, each vendor needs to be able to select which t-shirt they want to sell, and provide an optional price override.
This is how i imagine it looking...
Each vendor will have a column in their table that will contain the serialized data of a multidimensional array. The main array contains a sub-array for each t-shirt that i have in my t-shirt table. Each of those sub-arrays contains all of the override data (price, sizes offered, etc..).
How would i write the model, view, and/or edit page in a Joomla 2.5 component so that a vendor can select all of the options in the component admin page, and have it serialized in a column?
I am sorry if this is poorly explained and PLEASE PLEASE PLEASE don't hesitate to ask if you need further information in order to assist me.
Thanks!
I hate to say it, but I don't think that there is a "standard" method to do this in Joomla 2.5. Joomla has all kinds of ways to interact with the database and use their standard classes, but none of the classes are designed to work with serialized data to the best of my knowledge, so you would be stuck building all of the pieces by hand.
That being said, in general the model, should handle retrieving and storing the serialized data, the view would request any data in the database from the model, and the edit page should unserialize the data and display it in a way that your vendors can add their overrides. Beyond that it would be up to you to code each piece in your own way.
I have a situation:
I have products that are in a CodeIgniter Cart custom store.
Each product has an ID associated with it, but also has options for it (sizes).
These sizes all have different prices. (We're talking about photos being sold at different print sizes).
Because CI Cart updates, adds and deletes based on the product ID inserted, I am not able to insert one product with 2 different sizes.
As of now, the only solution I can think of is to pass the ID to the cart as IMAGEID_OPTIONID so that it contains both IDs.
However, I thought there might be an easier, more uniform way of doing this?
Or a better solution than an ID that isn't (on it's own) associated with anything specific unless i explode it..?
I recently built a site that had these constraints. In short, you'll want to create a distinction between "products" and "product groups". Think of it as managing the most discrete data units. In reality, shirt X sized medium is actually a different thing than shirt X sized large...doubly so if you have prices that are built on these qualities (this becomes more realistic when you consider cloth patterns or colors).
So anyway, if you have a "groups" table, a "product_groups" table, and a "products" table, you can keep all of these ideas distinct. On your products table, you can have columns for "size" and "color" (and any other distinguishing property you can think of) and a column for "price". Alternatively, you can go even more hardcore and make separate pricing tables that match up prices to unique products (this would be especially useful if you want to keep track of historical prices and discounts).
Then in your cart you can simply attach product_ids to cart_ids and perform a couple of joins to determine what "group" this product is a part of, what pictures are in that group (or exist for that product), and so on. It's not a simple problem, but following this line of thought should help get you on the right path.
One last point: keeping track of unique products like this also makes inventory accounting much, much more straightforward.
I have a customer who retails third party batteries, and some batteries can replace several OEM models.
For instance, 3rd party SKU 12345 may replace Toshiba N23 and HP 53214, thus my customer would like to create two products with the same SKU in front end (they are essentially the same product). However, Magento by default does not allow duplicated SKU.
My current solution is to set SKU to not required from the backend, and add another attribute called Model that allows duplicated values, and display the Model in front end.
Is there a better way to do this? Or is it possible to allow duplicated SKU?
Tian Bo
Noble Technologies
It sounds to me like you've found a good solution. I'm not so sure you should try to have duplicate values for SKU for two reasons.
First the whole point of SKU is that it is a unique identifier. That's its only reason for existing. If you're going to have duplicate values, then it's not a unique identifier; it's just another attribute. But of course Magento still needs a unique identifier to work, which means that this is an extra field, which takes us exactly where you are now.
That said we come to my second point which is this... I'm not exactly a Magento guru, but I've built my share of e-commerce sites and one thing I've learned is that they depend on certain unbreakable rules to work properly. One of them is that unique identifiers are unique, both on the database and application level. As such, a large part of the website depends on this to function correctly. Which I'm pretty sure goes for Magento too.
So trying to change such a basic premise in something so complicated will only lead to horrors and a slow descent into madness.
This sounds like a good solution that I extended a bit further, however what I did with multiple store was to create a visible attribute ITEM_SKU (Item SKU) - make it visible and searchable and then concatenate the store_id to Magneto SKU to make it unique.
So SKU becomes (Store_id "-" SKU).
It surprises me how often people are willing to break who-knows-what parts of Magento, just to get a specific piece working how they expect.
The proper way to allow for duplicate skus is NOT to (unless you'd like to re-write large parts of the framework). You CAN, however, add a custom attribute to products that shares all the same settings as "sku" minus the setting that requires values to be unique.
Changing product pages, emails, etc to show this value instead will require a little extra work but will save you headaches later.
Why don't you create 1 product (SKU 12345) and list this product in multiple categories. So your multiple categories will be Toshiba and HP. The same product (SKU 12345) will be listed in Toshiba and HP.