jsqu99 / emporium Goto Github PK

EDIT- it looks like we have consensus on multiple categories. @romul has proposed the idea of a 'main category' so feel free to comment on that.

I initiated a discussion on slack that I'd like to discuss and use as a vehicle to reach a consensus on whether or not products should have multiple categories:

jsqu99 [7:40 AM]
@romul: I’m trying to seed some test product/category data for some expirementation. I’m looking at our schema and it looks like our product table has a category id. Products should belong to more than one category, correct? Should we remove that category_id and have a product_categories table ? Similar to the product_properties table? I don’t recall all of the details we talked about when discussing treating the categories and properties similarly. thoughts?

jsqu99 [7:40 AM]
https://raw.githubusercontent.com/jsqu99/emporium/master/docs/data_model/emporium_erd.png (207KB)

kolorahl [8:57 AM]
Excuse my ignorance if I didn’t read some earlier conversation describing this, but what is a “product property” supposed to be? Intuitively I think of something like, “the color, size, or other ‘physical’ properties of a product.”

kolorahl [8:58 AM]
I ask because properties don’t necessarily directly relate to SKUs, so I’m wondering if I’m thinking of the term incorrectly. (edited)

jsqu99 [10:32 AM]
so there was some early discussion & agreement on merging 2 principles that those who worked on the rails ‘spree’ proejct are accustomed to: option types/values and product properties

jsqu99 [10:32 AM]
in spree, option type would be color. option value would be red, green, or blue

jsqu99 [10:33 AM]
so for a ’t-shirt’ product, you could create 3 variants

jsqu99 [10:33 AM]
product property would be:

jsqu99 [10:33 AM]
manufacturer: gildan

jsqu99 [10:33 AM]
material: cotton

jsqu99 [10:33 AM]
so options would be selectable by the user, and properties more ‘static'

jsqu99 [10:34 AM]
but in emporium we decideed to merge these concepts. we had a great discussion about this but now all is lost thanks to slack

kolorahl [11:01 AM]
If “manufacturer” is a property, and “gildan” is a product_property, then there should not exist a sku_id tied to that property because that manufacturer could (and likely will) have more than one SKU associated with it.

jsqu99 [11:02 AM]
i think gildan wold be a property_value or something…need to look at schema again

jsqu99 [11:03 AM]
disregard that

jsqu99 [11:03 AM]
oh, product properties are at the product, not sku, level

jsqu99 [11:03 AM]
https://raw.githubusercontent.com/jsqu99/emporium/master/docs/data_model/emporium_erd.png (207KB)

kolorahl [11:26 AM]
I also think having more tables representing specific kinds of properties that we know every product has would be beneficial. Every product, for example, has a manufacturer. And many times a product has one or more models (model being synonymous with version in this case), so we could have a versions or models table that relates to products.

jsqu99 [11:29 AM]
not sure i agree that a property-specific table is a good idea. not sure what the value-add is on that. “downloadable song” doesn’t have a manufacturer

kolorahl [11:30 AM]
Whoever is supplying it is the “manufacturer”. The song didn’t pop in from the aether =P

jsqu99 [11:31 AM]
yeah but the term doesn’t fit the domain very well, agreed? i just had a great 1 hour conv w/ @cory. We talked about some good next steps…certainly the data model has some rough spots, but we talked about getting started w/ a basic e-commerce flow from the front end perspective next as a way of starting to flesh out where the concurrency should come in

kolorahl [11:32 AM]
I agree that the name isn’t ​_great_​, but even from a customer perspective I definitely believe every product comes from some individual or company. Whatever term we want to use for that is the kind of relationship I’m talking about.

kolorahl [11:33 AM]
It could instead be a “vendor"

kolorahl [11:33 AM]
“merchant"

kolorahl [11:33 AM]
“supplier"

kolorahl [11:34 AM]
That’s all I can think of without getting too random.

romul [12:53 PM]
@jsqu99:

Products should belong to more than one category, correct?
We had the discussion with @cory about that. But we could not find a case when it's needed to have more than one category for a product. Don't forget, that in our case Category means Category, not Taxon, so something like Brand would be a separate model or a property.

jsqu99 [1:01 PM]
Hmmm…not sure I recall. If I have a bicycle, and I want to say it can be ‘exercise equipment’, ‘transportation’, or ‘things with wheels’, how would I model that in our data model?

romul [1:04 PM]
@kolorahl: I guess, you are talking about Brand model.

kolorahl [1:05 PM]
@romul: Brand is definitely a good property to have, but the person selling something is also great to have (if you want a system where you have vendors that might resell brand items) (edited)

romul [1:06 PM]

I want to say it can be ‘exercise equipment’, ‘transportation’, or ‘things with wheels’
What for? Availability of one product by 3 different URLs is SEO-killer

romul [1:09 PM]
@kolorahl: oh, something like Supplier or Dealer?

kolorahl [1:10 PM]
Yeah, basically. So customers could filter based on a particular supplier they might trust.

kolorahl [1:11 PM]
I’m basically trying to think how Amazon and other popular websites do online commerce, because keeping it familiar will be a big boon to customer usability.

romul [1:11 PM]
it would be helpful for SaaS-like platform (when many sellers could sell products on one platform), but I'm not sure, that it should be in core schema.

romul [1:12 PM]
the most of stores have only one Distributor, so I think it's a good candidate to built-in extension

romul [1:13 PM]
so, end-developer could enable/disable related functionality if needed

jsqu99 [2:16 PM]
@romul if i wanted to do soemthing like:
jsqu99
[2:16 PM]
Uploaded an image: Amazon_com__acquire.png

Add Comment

jsqu99 2:16 PM

jsqu99 [2:18 PM]
those are all valid categories, right?

kolorahl [2:21 PM]
True, I think Amazon will allow a product to belong to multiple categories.

kolorahl [2:23 PM]
There was an article I found on reddit, though I don’t believe I saved it, where they were talking about how your code is easier to use and maintain if you program for “zero or more” collections.

romul [2:24 PM]

those are all valid categories, right?
right, but if you dive in them, you will see different products

kolorahl [2:24 PM]
Instead of worrying about zero, one, or multiple of something, and in which cases you have each of those, creating a standard for the “zero or more” collection allows you greater maintainability, better abstraction, easier use.

kolorahl [2:25 PM]
So if we do add categories for products, there’s basically no harm in saying, “set it up to accept zero or more categories per product"

kolorahl [2:25 PM]
You can enforce limitations later in the code or the database, when adding and removing categories.

romul [2:25 PM]
so, the case at the screenshot is more about search hints, it shows in which categories you could find products like your query.

kolorahl [2:26 PM]
As for Amazon having different products for different categories, Call of Duty for the PC actually seems to exist in at least three categories: Software > Digital Software, Video Games > Digital Software, and I believe Video Games > Digital & DLC

kolorahl [2:28 PM]
To be more precise, if you search for "Call of Duty Black Ops III” you can find it under Software, Video Games > PC Games > Digital Games & DLC, Video Games > PC Games > PC Games, and Video Games > Digital Games

kolorahl [2:28 PM]
It is possible it only has one category, underneath all that, and some other component is relating them across the different searchable categories.

romul [2:28 PM]
i guess, it was not the best example.. there is too much "Call of Duty" on Amazon 😀

kolorahl [2:29 PM]
But you can see it here: http://www.amazon.com/Call-Duty-Black-Digital-Code/dp/B00WNETVCE/ if you scroll down to "Product Details”, that this one product exists in at least 3 categories, as far as a user is concerned.
Amazon.com: Call of Duty: Black Ops III - PC [Digital Code]: Video Games
(edited)

romul [2:31 PM]
yeah, now I got it )

romul [2:35 PM]
though I'm unsure still, that it's really needed... I remember many issues caused by N:M relation of products and taxons in Spree

romul [2:35 PM]
for example, with breadcrumbs navigation

romul [2:36 PM]
or with permalinks (you couldn't use category name in URL of product, if it could have more than one category)

jsqu99 [2:46 PM]
it just seems �like there’s not an upside to only allowing one category. this can be separate from permalinks, can’t it?

jsqu99 [2:47 PM]
good night all. i have to go

romul [2:48 PM]
I understand that it's possible to inventar several categories for each product, but I haven't got a clue why it would be helpful.

romul [2:58 PM]
Imho, imaginary benefits on the one hand and real issues on the other hand.
I really had to add taxon_id column to spree_products table in one of my projects, b/c join-table was terrible bottleneck (3x boost of catalog performance after this change)
So, I propose in any case preserve something like main_category_id in products table. It would be excellent for the most of stores.

romul [2:59 PM]
good night :simple_smile: