Discuss Category / Product relationship

[jsqu99]

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 :grinning:

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:

[jsqu99]

My vote: Allow multiple categories for a product.

[tyler-eon]

I feel like categories are more like "tags", but you can have nested tags so if you belong to a child tag you basically belong to its parent tag. That also follows the "zero or more" or "one or more" convention, which I personally like, as opposed to "one or none." So if we do have categories we should definitely allow for multiple in our database and logic, and then allow developers to add their own restrictions later if they so choose.

[jsqu99]

from slack:

romul [11:16 AM] @jsqu99: in general I don't mind to have many categories for the product. But I'd like to have something like main_category_id too. the same concept could be used with images... for example, when you select products from db, selecting of one entry by association is much more efficient than selecting all of them.

romul [11:17 AM] b/c any extra JOIN reduces scalability

jsqu99 [11:18 AM] thanks @romul. Would you mind commenting on the github issue just so we don’t lose the conversation? I can paste your comment there this time

jsqu99 [11:18 AM] https://github.com/jsqu99/emporium/issues/15 (edited)

romul [11:18 AM] and b/c I had to do it by myself with Spree for any non-trivial project :simple_smile:

jsqu99 [11:19 AM] we can use indexes to mitigate the join cost?

[dimitarvp]

Since this is the only opened issue in this repo, I'll comment here.

Authors, what's the status of this project? I'm currently involved in a very legacy Spree project (using v2.2) and I am looking forward to using Elixir more since I already had a few positive experiences with it. The fact that it's based on Erlang which is even more stable than Google's Go also helps a lot.

Anyhow. Do you guys have a feature matrix of some sort? Do you have a comparison article or spreadsheet with Spree and Magento?

You know, I would actually help you even though my Elixir experience is almost zero so far. Still, having used 7+ languages in my career should make this easier. :)

But right now I need to evaluate a few alternatives to Spree and I'd like to avoid Magento if possible -- it being written in PHP being a huge contributing factor. The moment is perfect for that and I'll be really sad if you guys just keep quiet.

So let's recap the two questions:

1. Where are you in terms of features, stability, comparing with mature e-commerce frameworks?
2. What would you need help with?

[jsqu99]

Unfortunately this project never really got off the ground. I got super-busy and eventually lost interest unfortunately. I know Rob Conery was doing something w/ elixir ecommerce...i'd recommend checking that out.

On Thu, Apr 14, 2016 at 11:16 AM, dimitko notifications@github.com wrote:

Since this is the only opened issue in this repo, I'll comment here.

Authors, what's the status of this project? I'm currently involved in a very legacy Spree project (using v2.2) and I am looking forward to using Elixir more since I already had a few positive experiences with it. The fact that it's based on Erlang which is even more stable than Google's Go also helps a lot.

Anyhow. Do you guys have a feature matrix of some sort? Do you have a comparison article or spreadsheet with Spree and Magento?

You know, I would actually help you even though my Elixir experience is almost zero so far. Still, having used 7+ languages in my career should make this easier. :)

But right now I need to evaluate a few alternatives to Spree and I'd like to avoid Magento if possible -- it being written in PHP being a huge contributing factor. The moment is perfect for that and I'll be really sad if you guys just keep quiet.

So let's recap the two questions:

1. Where are you in terms of features, stability, comparing with mature e-commerce frameworks?
2. What would you need help with?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jsqu99/emporium/issues/15#issuecomment-209996870

[dimitarvp]

Could you please give me a link, @jsqu99?

EDIT: It might also help if you mention the project's status in the README.md file.

[jsqu99]

I just googled:

Rob Conery elixir ecommerce

and the first hit that came up ( https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiQuOH_uY7MAhVM5SYKHcMqAxQQFggfMAA&url=http%3A%2F%2Frob.conery.io%2F2016%2F02%2F10%2Flet-s-build-something-with-elixir%2F&usg=AFQjCNH4n00VoBXY4msGhza90mLGTaKlSg&sig2=MahHcrUGI11TX_EoUauC3A) was the link you are looking for

On Thu, Apr 14, 2016 at 11:33 AM, dimitko notifications@github.com wrote:

Could you please give me a link, @jsqu99 https://github.com/jsqu99?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/jsqu99/emporium/issues/15#issuecomment-210005412

[dimitarvp]

Thank you. Seems like he did 2 enthusiastic posts but his 3rd post is around 2 months late. Shame.