To Combine or not to combine that is the question

V1.5.7

I have nearly finished a products location add on that creates a table to store the location of the product against the products_id. I also want to store the customs hs code. I was wondering if it would be better to write a separate plug in with an other addition table or whether to combine the two aspects into a single table. Thus one table
products_id, products_location, products_hscode

it would also mean combining the processing code for both to add the capture fields (not an issue) or keep them separate as two distinct processes.

From my perspective adding a single table seems easier for me. But I do not know what the best way to go would be from a general perspective.

Any views/input welcome.

I think if you were to call the table products_custom_information then it would make sense to put all 3 fields there. ("custom", "bespoke", "extra", "my", etc would work too)

If you're getting into something where "location" refers to a broader warehousing infrastructure then calling it products_location would be relevant. But if your plugin isn't offering that, then I suggest not squatting on that naming in case it clashes with something that aims to focus and expand upon that.

Quote:

---

Originally Posted by brittainmark

V1.5.7

I have nearly finished a products location add on that creates a table to store the location of the product against the products_id. I also want to store the customs hs code. I was wondering if it would be better to write a separate plug in with an other addition table or whether to combine the two aspects into a single table. Thus one table
products_id, products_location, products_hscode

it would also mean combining the processing code for both to add the capture fields (not an issue) or keep them separate as two distinct processes.

From my perspective adding a single table seems easier for me. But I do not know what the best way to go would be from a general perspective.

Any views/input welcome.

---

i would separate thinking about your functionality (ie plugins) from your schema (db tables, fields, etc.)

my limited experience with harmonize codes suggest a 1 to 1 relationship between product and hs codes.

no such 1 to 1 relationship exists in an inventory system, unless enforced from a programmatic standpoint.

products can potentially exist in multiple warehouses with multiple locations (ie bins) in a warehouse.

whether you want to account for such things is a different story.

but when thinking about and designing a schema, i would design for the relationships, and then code what you want to offer.

in this scenario, i would keep the data in separate tables. and whether you want to alter the products table to add a field for the HS code is a very possible solution.... although certainly open for debate.

hope that helps!

Thanks both comments really useful. I did not want to modify core tables as it can lead to problems later. I suppose it was lazy thinking combining in to one. For the Hs customs code I was also thinking of adding a customs invoice. so keeping separate i think is the way to go. For the product location I have just done something simple for me Adding a code to the product so that i know its location. I will probably call it simple product location as I have not designed it for multi warehouse location only having the one stock location myself.

Quote:

---

Originally Posted by brittainmark

I did not want to modify core tables as it can lead to problems later. I suppose it was lazy thinking combining in to one. For the Hs customs code I was also thinking of adding a customs invoice. so keeping separate i think is the way to go.

---

a few things:

• modifying core ZC DB tables by adding fields, in my experience, does not cause later problems.
• improperly setting up the field when your db config is in strict mode can result in problems, but that problem would exist in a new table as well as in an existing table.
• modifying core code is where one can lead to problems later. which i am not at all recommending.
• with regards to a customs invoice, again, i am not sure what that has to do with the schema.
• when creating a customized invoice for a customs authority, you are still listing product model numbers, descriptions, etc.
• all of that data originates from the products and products descriptions table. which is then carried over to the orders_products table.
• now i'm guessing you want to add a harmonized code below that data on your customized invoice. how do you draw the conclusion that it needs a separate table?

there are plenty of implications down the road based on the decisions you make here. i know for my clients, i originally set up a separate table for various other elements that they needed to describe a product. in retrospect i wish i would have just added those fields to the products table. retrieving that data when needed is far easier than when it is in an additional table especially given the current scope of the product class.

just a little food for thought.

btw, my plugin here:

https://www.zen-cart.com/downloads.php?do=file&id=2279

could very easily be modified to update a single location field.

it uses the v157 encapsulated plugin which i think is a vast improvement for creating plugins.

best.

Nice plugin but not what I need. Am also going down the zc_plugins route.
I'll think on what you said about modifying the base tables. Don't know why I feel nervous about doing it, the correct place for the data is the products table.
RE with regards to a customs invoice, again, i am not sure what that has to do with the schema. I was trying to give you a bit more background into what I was going.