I'm trying to describe a Car object that has multiple options regarding the engine or gearbox, that is referenced by an aggregateOffer as the itemOffered.
I want to indicate that the said Car can have either a manual or automatic gearbox, can be new or used, accept diesel or other fuels etc. The two options I see are the following :
1) Make a list with possible gearboxes and other options
"itemOffered" : {
"vehicleTransmission": ["Automatic","Manual"],
"fuelType": ["Diesel", "Essence"]
}
Would this be interpreted as follows : the car has either a manual OR an automatic gearbox ?
I'm affraid the semantic behind this would suggest that the said car has both.
2) Make a list of cars with all possibilities
"itemOffered": [
{
"#type": "Car1",
"fuelType": "Essence",
"vehicleTransmission": "Automatic" },
{
"#type": "Car2",
"fuelType": "Essence",
"vehicleTransmission": "Manual" }
]
But this would be potentially very big, as I have multiple car offers with several different options, I would end up listing my entire database.
To clarify, the point of this Car object is to be attached to an aggregateOffer on a page where only the aggregateOffer is displayed and not every single offer available.
The second interpretation is correct. If you have one Car with multiple fuelType values, all of these values apply to this Car; they don’t represent alternatives.
Anyway, the AggregateOffer doesn’t seem to be suitable for your case. This type is intended for multiple offers of the same product, not for multiple offers of different (albeit similar) products:
When a single product is associated with multiple offers (for example, the same pair of shoes is offered by different merchants), then AggregateOffer can be used.
If you don’t want to list/repeat so many properties for each Car, you could make use of the ProductModel type. You can link ProductModel items with the isVariantOf property. Each variant model will inherit the features from its base product model, unless you "overwrite" them in the variant model. Each Car would then use the model property to refer to its product model.
However, if you have a specific structured data consumer in mind, they might not support this more complex structure.
Related
I need to create a datastructure in GraphQL (MongoDB as database) which represents the following schema:
A bill can have multiple articles
One article has a article-group-number and numerous attributes that 100% depend on the article-group-number and may vary heavily between these groups.
So one article may look like this:
{
article-group-number: 100,
length: 5.5
}
Another article may look like this:
{
article-group-number: 101,
width: 2
}
There may even be articles that have a reference to another article (but no circular structure).
I need to be able to create and maintain different validation-rules (functions) for each article-number.
How should i do this?
I was thinking about union types in GraphQL but those can only be read, not written (by "mutation") at this point in time.
Am i supposed to save those articles as pure JSON-data and do all validation by hand? This way i would loose the logical structure since this JSON-data field would just be some sort of a "messy data-blob" in my eyes because all logic is lost by passing through GraphQL.
Isn't there a more clean way?
Two options:
You could take a cue from GraphQL itself -- the __Type type that is used in schemas has a "kind" field, and a lot of attributes that depend on the kind of the type. An object type, for example, can have fields, but other kinds of types cannot. GraphQL just puts all of the possible attributes in the __Type type and lets them take null values when they aren't applicable to the type's kind. You could do a similar thing, and just let your articles have all possible attributes.
Or you could use a union of article types, maybe all implementing a common article interface. This is not really a problem for mutations. Since mutations are in a completely different namespace from queries, they can do whatever you want -- the type you mutate doesn't have to be the same as the type you query, and in fact usually isn't.
Both ways work. The second way is more complicated, though, so if you're going to do that then make sure you're going to get some kind of benefit from it.
Trying to get my hands dirty with MongoDB, coming from a relational database background.
I believe one of the main concepts of MongoDB is to keep as much data together as possible.
Imagine I create an application that have products and categories, and I store products this way:
Products collection
{
"_id": "30671", //main item ID
"department": "Shoes",
"category": "Shoes/Women/Pumps",
"brand": "Calvin Klein",
"thumbnail": "http://cdn.../pump.jpg",
"title": "Evening Platform Pumps",
"description": "Perfect for a casual night out or a formal event.",
"style": "Designer",
…
}
Categories collection
{
"_id": "12356",
"name": "Shoes"
…
}
If I update a category name, would I need to run a huge update command to update all products as well? Or in this scenario it would be better to actually store the category ids against the products instead of their names (like we would do on a relational database)?
Thanks
In general there is no "one-size-fits-all" approach in MongoDB like it is in relational database world. In a relational schema design, it is a no-brainer to put Category in a separate table. In fact, it is almost a requirement to do so during normalization process.
In MongoDB, schema design almost entirely depends on what you need and your use case more than any rule-of-thumb or any formulated requirements. Of course, there are pluses/minuses for each choice. For example:
If you find in your use case that Category doesn't change much (or at all), then you can safely put it inside the Products collection. However, should you need to rename a category, then yes you would need to update all the products belonging to that category.
If you find that your use case requires flexibility in changing category names, then you may want to put it into a separate collection and refer to it like in a relational design. However, returning a product may not be as performant since now you need two queries instead of one (or a lookup).
I noticed that you used "category": "Shoes/Women/Pumps" in your example. In MongoDB, you can put that into an array if your use case allows it, e.g. "category": ["Shoes", "Women", "Pumps"]. This may make the field easier to index (again, depending on your use case).
In short, there is no right or wrong in MongoDB schema design with one caveat: usually the wrong thing to do is trying to emulate a relational design in MongoDB, since it goes against the grain.
You also may find these links helpful:
6 Rules of Thumb for MongoDB Schema Design: Part 1, Part 2, Part 3
Data Models
Use Cases
So i'm setting up my ld+json structured data, using Schema.org schemas. I am adding products with Offers but they only have a single price parameter.
I also looked at PriceSpecification too, but there is only "range" and "price".
Should I use 2 PriceSpecifications (or 2 Offers?) with visibly different names, or is there another option I haven't come across? Don't want search engines to get confused.
Thanks for any help.
You can use multiple PriceSpecifications. However "typically, only the subclasses of this type are used for markup." UnitPriceSpecification would be the best fit, or the setup price can be of type DeliveryChargeSpecification.
Alternatively, you can use a single CompoundPriceSpecification with multiple priceComponent properties, each of type UnitPriceSpecification. "The name property of the attached unit price specification for indicating the dimension of a price component"
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I’m starting a new web project and have to decide what database to use. I know, the question is very long but please bear with me on this.
I am very familiar with relational databases and have used frameworks like hibernate to get my data from the DB into Objects. But I have no experience with noSQL DBs. I am aware of the concepts of Document, Key-Value, etc. types.
While I do my research one question pops out every time and I don’t know how someone would handle this in noSQL DBs like MongoDB or any other Document-Typed noSQL DB where consistency takes top priority.
For example: let’s assume that we are creating a small shopping management system where customers can buy and sell stuff.
We have:
CUSTOMERs
ORDERs
PRODUCTs
A single CUSTOMER can have multiple ORDERs and an ORDER can have multiple PRODUCTs.
In a traditional RDBMS I would of course have 3 tables.
In the first version of our application, the front end for the customer should display his/her personal data, ORDERs and all the PRODUCTs he or she bought per order. Also which products are available for sale. So I guess in noSQL I would model the CUSTOMER class like this:
{
"id": 993784,
"firstname": "John",
"lastname": "Doe",
"orders": [
{
"id": 3234,
"quantity": 4,
"products": [
{
"id:" 378234,
"type": "TV",
"resolution": "1920x1080",
"screenSize":37,
"price": 999
}
]
}
],
"products": [
{
"id:" 7932,
"type": "car",
"sold": false,
"horsepower": 90
}
]
}
But later I want to extend my application to have 3 different UIs instead of only the first one:
The CUSTOMER Dashboard where a customer can view all his/her orders.
The PRODUCT Dashboard where a customer can add or remove products in his/her store.
THE SOLD Dashboard where a customer can view all sold PRODUCTs ready for shipping.
One very important thing to consider (the reason why I even bother asking this question): I want to be flexible with the classes like PRODUCT because products can have different properties. For Example: A TV has screen size and resolution while a car has horsepower and other properties. And if a user adds a new product, he or she should be able to dynamically add those properties depending on what he/she knows about it.
Now to some practical use cases of two fictional users Jane and John:
Let's say, Jane buys from John. Does that mean i have to create the PRODUCTs two times? One time as a child of Jane's ORDER and another time to stay in the "products" property of John?
Later Jane wants to view all products that are available from any user. Do i have to load every user to query the "products" property to generate a list of all products?
In version 2 of the application i want to enable John to view all outgoing orders (not orders he made but orders from other users who bought stuff from him) instead of viewing all sold products. How would this be done in noSQL? Would i now need to create an "outgoing" array of orders and duplicate them? (an outgoing order of Jane is an incoming order of John)
Some of you may say that noSQL is not right for this use case but isn’t that very common? Especially when we do not know what the future brings? If it does not fit for this use case, what use case would it fit into? Only baby applications (I guess not)? Wasn’t noSQL designed for more complex and flexible data?
Thank you very much for your advises and opinions!
EDIT 1:
Because this question was put on hold because of the unprecise question:
I made a very clear and simple example. So my question is not general about the use of noSQL but how to handle this specific example. How would a experienced noSQL user handle this use case? How to model this data? A recommendation to simply not use noSQL at all for this use case is also a valid answer to me.
I simply want to know how to use a noSQL database but still be able to manage entities and avoid redundancy.
For example: Are MongoDB's DBRefs/Manual refs a good way to achieve this? Performance issues because of multiple queries? What else to think about? I guess these questions can probably be answered quite well.
There probably isn't the one right answer to your question. But I'll make a start.
While it is technically possible in NoSQL to store some business entity together with all entities that are transitively linked with it (like Customer, Order, Product), it is't always clever to do so. The traditional reasons for separating entities, namely redundancies and therefore update and delete anomalies, don't just go away because a different platform is used.
So if you stored the product description with every customer who buys or sells this product, you will get update anomalies. If you have to change the screen size from 37 to 35, you'll have to find all customer records containing this product, which can be quite cumbersome.
Also, building up such a deep nested structure favors one direction of evaluating those structures over all other directions. If you put all orders and products into the customer document, this is very fine for getting a comprehensive view for a customer: whatever she bought throughout her lifetime. But if you want to query your database by orders (which orders need to be fulfilled tonight?) or products (who ordered product 1234?) you'll have to load tons of data that are of no interest to this query.
Similar questions are due to storing all orders with a customer. Old orders will sometimes still be of interest, so they may not be deleted. But do you want to load lots of orders everytime you load the customer?
This doesn't mean not to make use of the complex structuring made possible by a document store. As a rule of thumb, I would suggest: As long as the nested information belongs to the same business entity, put it into one document. If, e.g., the product description has some hierarchic structure, like nested sections consisting of text, pics, and videos, they may all go into one document. But entities with a totally different life cycle, like customers, orders, and suppliers, should be kept separate. Another indicator is references: A product will frequently be referenced as a whole, e.g. when it is ordered by a customer or ordered from a supplier. But the different parts of the product description may possibly never be referenced from the outside.
This rule of thumb wasn't completely precise, and it's not supposed to be. One person's business entity is another person's dumb attribute. Imagine the color of a car: For the car owner, it's just a piece of information describing a car. For the manufacturer, it's a business entity, having an availability, a price, one or more suppliers, a way of handling it, etc.
Your question also touches the aspect of dynamically adding attributes. This is often praised as one of the goodies of NoSQL, but it's no free lunch. Let's assume, as you mentioned, that the user may add attributes. That's technically possible, but how will these attributes be processed by the system? There won't be a specific view, nor specific business rules, for those attributes. So the best the system can do is offer some generic mechanism for displaying those attributes that were defined at runtime and never reflected in the program code.
This doesn't mean the feature is useless. Imagine your product description may be complex, as described above. You might build a generic mechanism to display (and edit) descriptions made up of sections, texts, images, etc., and afterwards the users may enter descriptions of unlimited width and depth. But in contrast, imagine your user will add a tiny delivery date attribute to the order. Unless the system knows specifically how to interpret this date, it will just be a dumb piece of information without any effect.
Now imagine not the user, but the developer adds new attributes. She has the opportunity to enhance the code at the same time, e.g. building some functionality around delivery dates. But this means that, although the database doesn't require it by its own, a new release of the software needs to be rolled out to make use of the new information.
The absence of a database scheme even makes the programmer's task more complicated. When a relational table has a certain column, you may be sure that each of its records has this column. If you want to make sure that it has a meaningful value, make it not null, and you may be sure that each record contains a value of the correct data type. Nothing like that is guaranteed by schemaless databases. So, when reading a record, defensive programming is needed to find out which parts are present, and whether they have the expected content. The same holds for database maintenance via administrative tools. Adding an attribute and initializing it with a default value is a 2-liner in SQL, or a couple of mouse clicks in pgadmin. For a schemaless database, you will write a short program on your own to achieve this.
This doesn't mean that I dislike NoSQL databases. But I think the "schemaless" characteristic is sometimes overestimated, and I wouldn't make it the main, or only, reason to employ such a database.
I should introduce the products of a company that creates chemical, mineral and agricultural raw materials.
To explain more clearly, some examples are Ammonium Sulfate (as an agricultural product), Phosphate (as Minerals) and Sulphuric acid as a chemical raw material.
Reviewing http://schema.org/Product, http://schema.org/Thing, https://schema.org/docs/meddocs.html and also https://schema.org/MedicalEntity, I don't know which one (or maybe another template to use) are the best template to make use of.
As you said, these are products (i.e., they offer these, right?), so the Product type seems to be appropriate.
MedicalEntity (or one of its sub-types) would only be appropriate for those products that are "related to health and the practice of medicine". If that’s the case, you could add it as additional type.