A book is a "product" but comes in several flavors, print, ebook and audio edition. Each is identified with an ISBN, which seems to map well as the product sku. However, the flavors share information in common, such as author and publisher.
I suppose this kind of relationship mapping is common in other domains besides books; what should we be thinking about, while going about designing this?
I did it with this: www.inuedizioni.com
in Drupal 7 and Drupal Commerce.
It is still in development, with Commerce functionalities still inactive, though implemented, for Commerce Files, so far.
It has been quite hard project, especially at the beginning, trying to assess possible alternatives (Drupal 6 and Ubercart, for instance). But is a very successful story, so far ...
Thanks, that was helpful, especially reading through the discussion http://drupal.org/node/1199602#comment-5365636; basically answered my question about how to structure the various formats of a book (print, ebook, audio edition), and then represent them in a product display. Makes all the sense in the world.
Now that I've got the idea of products (entities) and product displays (nodes), I'm looking at different formats of the book: print, ebook, audio. This can be done under a common product entity, "book", with a attribute for format. A distinct sku, (entity) for each format. These are grouped under a product display, and that works fine.
What would be the advantage or disadvantage of creating a separate product entity type for the formats (print, ebook, audio)?
I suppose one consideration is that there can be sub-formats to each format, such as hardcover and paperback for "print", epub, pdf or imobi for ebook.
What do you think? These kind of design decisions are cheap at inception and dear, down the road.
So now we've defined content types:
Title
Author
Publisher
And a product types of :
print book
eBook
audio book
Each of the product types include a node reference to Title, Author and Publisher nodes.
In this way, the titles, authors and publisher information is maintained each in a single node, while the attributes of product are those which are really distinct to the sku.
I'm not sure yet what this will look like downstream, when slicing and dicing with views, so we'll see... I think it will give us more flexibility in representing information, but more difficulty in importing.
I'm also building an online bookstore with Drupal Commerce. Have you made any progress since your last post here? Does the schema you outline above work out?
Comments
Creating products in drupal commerce
A book is a "product" but comes in several flavors, print, ebook and audio edition. Each is identified with an ISBN, which seems to map well as the product sku. However, the flavors share information in common, such as author and publisher.
I suppose this kind of relationship mapping is common in other domains besides books; what should we be thinking about, while going about designing this?
I did it with this:
I did it with this: www.inuedizioni.com
in Drupal 7 and Drupal Commerce.
It is still in development, with Commerce functionalities still inactive, though implemented, for Commerce Files, so far.
It has been quite hard project, especially at the beginning, trying to assess possible alternatives (Drupal 6 and Ubercart, for instance). But is a very successful story, so far ...
You can read some more from here:
http://drupal.org/node/1199602#comment-5365636
http://www.italomairo.com/cms/node/13
http://groups.drupal.org/node/128514#comment-716359
and here (if you understand Italian):
http://roma2011.drupalday.it/sessions/il-nuovo-catalogo-informatizzato-e...
http://www.slideshare.net/italomairo/drupal-7-drupal-commerce-per-il-il-...
Digital Communication, Web 2.0 & Web Gis 2.0 Opensource
www.italomairo.com
email: itamair@me.com
Separation of "product" from "content"
Thanks, that was helpful, especially reading through the discussion http://drupal.org/node/1199602#comment-5365636; basically answered my question about how to structure the various formats of a book (print, ebook, audio edition), and then represent them in a product display. Makes all the sense in the world.
Book format as distinct product types, or just by attribute?
Now that I've got the idea of products (entities) and product displays (nodes), I'm looking at different formats of the book: print, ebook, audio. This can be done under a common product entity, "book", with a attribute for format. A distinct sku, (entity) for each format. These are grouped under a product display, and that works fine.
What would be the advantage or disadvantage of creating a separate product entity type for the formats (print, ebook, audio)?
I suppose one consideration is that there can be sub-formats to each format, such as hardcover and paperback for "print", epub, pdf or imobi for ebook.
What do you think? These kind of design decisions are cheap at inception and dear, down the road.
Products built around node references
So now we've defined content types:
Title
Author
Publisher
And a product types of :
print book
eBook
audio book
Each of the product types include a node reference to Title, Author and Publisher nodes.
In this way, the titles, authors and publisher information is maintained each in a single node, while the attributes of product are those which are really distinct to the sku.
I'm not sure yet what this will look like downstream, when slicing and dicing with views, so we'll see... I think it will give us more flexibility in representing information, but more difficulty in importing.
Any progress?
I'm also building an online bookstore with Drupal Commerce. Have you made any progress since your last post here? Does the schema you outline above work out?