0

I'm making an simple application that involves books, using a NoSQL database (MongoDB) -- I think I need to make a DB/schema that stores generic books and their information (title, author, etc.) and then another DB/schema that stores individual instances of books that users own (and user-specific information, such as when they started the book, their rating, etc.).

Should they be linked somehow (e.g. a Book item has a GenericBook as a property), or should the GenericBook database just be used for lookup/reference to populate the fields of a Book item when it's first created by a user?

It feels like a common pattern, but I'm not sure how this is usually designed.

  • 1
    The title of the question doesn't match the body. You're not asking about generic objects, you're asking about Books. Are you sure a relational database isn't more appropriate? – RibaldEddie Jun 14 '17 at 5:41
  • Sorry for the terminology misuse -- I named it that way because I think the the general problem can be framed as "how can I design a schema for an application that has (so-called) 'generic objects' and 'instances of objects' attached to particular users." The objects in this case being books isn't super relevant, I think. – Jess Jun 14 '17 at 5:47
1

It depends of your intended design.

If you consider creating two independent microservices, one for a book catalog, and one for renting/selling books (potentially originating from several vendor catalogs), you should go for replicating the information.

However, in a mote traditional design and especially if every user book is in the same catalog (and will remain there) you should consider having an association between the two tables (in an rdbms) or documents (in a document-based nosql). The common element for the link would be a unique identifier, like the isbn number.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.