I'm developing an e-commerce site and I'm facing a problem. The requirement I need to fulfill is: given a certain string like "lock", "tennis", "cinema" or "scaffold" entered by an user, I should display both profiles and product postings matching that query.
That leads me to these conclusions:
a) I should classify profiles (what they do): maybe some sort of "business category". I face a problem here, it's almost impossible to create a list that covers all the business activities in the world, so I've been reading some good questions here and liked the strategy of creating a 1 or 2 level hierarchy and then capture the user feedback automatically through reusable tags.
The idea here is to keep the keywords that are more likely to be thought of and so with best odds of being searched for.
By the way, is there a really good business category list out there that I'm missing?
b) I should classify products and services (what they offer): with a similar approach, I liked using some fixed categories and then let users use persistent tags. I ask you again if there is a category list out there that really rocks.
Questions:
1) Do you like what I've just described? Based on your experiences do you think it might work or will I drown in a tag sea?
2) Sometimes both product and business hierarchies are kind of redundant. There are some people that describe their businesses like "theater", "bank", "dentist" and that's not a product or service but rather what they actually are. But there are plenty of cases where people say "(sale/manufacturing) cars", "(manufacturing) pottery", and so on. Their business activity is chiefly determined by the product or service they're selling or producing. What's your take on this?
I did something like this is ror_ecommerce. I used a tree for product_types.
So you could sell:
Furniture => Livingroom => Chairs
Filtering by Livingroom would also give items that have a product_type pointing to Chairs.
To make it more complex I would first fight the business person.
Second I would create a model where product has many product_types. Thus you need a join table between product_type and product.
Answer to your question:
1) You will probably drown because categories are infinite. Limit the number of tags or make an admin interface that your business people can populate. If not your business folks will request you to do this work over and over again.
2) It sounds like Your tree would look like this:
sale/manufacturing => cars
sale/manufacturing => pottery
bank => personal
bank => business
thus if someone just wants a bank they get results for personal and business. but they can further refine the search to just personal banking.
It also sounds like the business and product hierarchies are completely redundant. I would really fight a business guy saying anything else because a future requirement will be to relate business and personal hierarchies. If they are the same it will be easy. You might want a type flag on the list for personal / business / both. it will be a lot easier to remove the flag if it's not needed.
Good Luck
Related
Basically, I'm kinda exhausted while thinking about the best possible way to structure my database for a recipe app I have planned and could need some help/ideas.
The goal is to make a recipe app including multiple languages(translated recipes) and which has features like a meal plan and shopping list, for example.
To achieve all that, I came up with this design of a database(Image below). It's important to have the ingredients as an own entity so that they add up in the shopping list. With the current design its really hard to filter by the total amount of calories, eg. "I want to see all recipes that have less than 500 calories".
The recipes only get added by me, meaning there will be probably never ever be more than 10 000 of them(In the absolute best case :D).
I would appreciate any help and also comments about other things like scalabilty/performance etc.
As I have looked all over for an answer to my question and found nothing of use, I can only assume a) I can't use Google b) I'm the only one stupid enough to not know the answer off my own back.... So would be greatful for any advice or support on this.
Basically I'm setting up a basic e-commerce site. I have the standard products, customers, orders, orderdetails, addresses, and cart tables in place.
What I'm struggling to envisage is how to incorporate cataloguing into my design. There will be hundreds of products and downs of account but not all the products will be available to each account/customer. One customer may only have 4 products in their catalogue to choose from but another may have 50. Would merely creating a seperate catalogue for each customer (CatalogueID against Account ID), at the risk of repeating data, be my only answer?
Hope this makes sense.
Cheers.
Is there some rule of thumb, in which direction to make the association when designing domain model?
For example, we have products in the stock. Stock status of a product is a rather complex data structure, containing enumerations of multiple variations of the product either being in the stock, being out of stock or being bookable. Thus we make a seperate object of the stock status associated with the product. Now the question is, if product object should have a reference to it's stock status, or stock status have a reference to a particular product.
First solution feels like, it's not the real concern of product knowing it's stock state. Product is just a product, and maybe we should manipulate them in different context, where stocking is not a concern. In the other hand, stock status being a root feels awkward, as when thinking about stock, first we think about a product being in the stock.
How to decide, which entity acts as a root for the association?
You are assuming that both concepts are tightly coupled, meaning, they belong to the same bounded context. This means both models become dependent on each other - which may be something you don't want because it causes complexity you may not want. After all, you mentioned it yourself: "it's not the real concern of product knowing it's stock state". So why add a relation to it?
You could consider them as two separate bounded contexts - no direct relation between them, except for the product ID which links the two concepts.
Navigability is something you should simply neglect as it is something purely artificial. If two things are related, they know about each other. Actio et reactio. Gravity. Love. Try hard to find something that works only in one direction. Blackmail. Spy mirrors.
Introducing navigability indeed has only meaning in implementation phase. You try to decouple things in order to reduce dependencies, now for good. And what you actually do here is to attach role names towards the navigation. Which in turn makes the arrows superfluous.
TL;DR; Just don't use arrows in UML modeling. Leave them for the Powerpoint League.
First solution feels like, it's not the real concern of product knowing it's stock state. Product is just a product, and maybe we should manipulate them in different context, where stocking is not a concern. In the other hand, stock status being a root feels awkward, as when thinking about stock, first we think about a product being in the stock.
When we think about shopping carts, we think about products in the shopping cart. Yet most of the time, the useful way to model cart items is with a reference back to the product.
My guess would be that you need to be thinking more about Stock, and in particular about its life cycle; how tightly coupled are the lifetimes of the two different ideas? If you have a situation where a single Product has a relation to two different Stocks (one in the past, one in the present; one at this location, another at that location), then storing that relationship in the product isn't right.
Problem
When the data have a tree structure of parent/child/grandchild entities, we often duplicate the information in the URL, specifying parent IDs, even if that's not necessary. What's the best way to design the RESTful API in such case? Can the URLs be shortened and the parent IDs omitted?
Example
The tree is as follows: The top-most entity is a product. Each product has 0-N reviews. Each review can have 0-M comments attached. In theory, there can be an arbitrary depth of this tree.
The naive RESTful API would look like this (assuming only GET endpoints):
/products ... list of products
/products/123 ... specific product 123
/products/123/reviews ... list of reviews for product '123'
/products/123/reviews/abc ... specific review 'abc'
/products/123/reviews/abc/comments ... list comments for review 'abc'
Hang on, wait a minute... The last two labels I have written do not say anything about product '123'. Yes, the review 'abc' belongs to that product, but as a human, I don't need to know that. And if the review ID 'abc' is unique among all reviews, neither does the computer.
So for example when we send an update (PATCH) request for review 'abc', we don't need to know whole hierarchy of parent objects up to the tree root (products), e.g that it belongs to product '123' in this case. Of course, we assume each object has an unique ID among all objects of that entity - but that's a natural behavior for example in RDBs, so many people (well, their APIs) are in this situation.
Questions
If the IDs of "child entities" are unique among all entities of that type, would it be best practice to design the API like this?
/reviews/abc ... specific review 'abc'
/reviews/abc/comments ... list comments for review 'abc'
/comments/xyz ... specific comment 'xyz'
If answer to (1) is yes, should an endpoint like this be valid as well? Why? Why not?
/products/123/reviews/abc/comments/xyz ... specific comment 'xyz'
If short URLs are allowed (or even preferred), isn't this a bit inconsistent then?
/products/123/reviews ... list reviews for product '123'
/reviews/abc ... specific review 'abc'
/reviews ... what should be here? all reviews?
Yes.
Depends - I wouldn't recommend it, but if you find a use case for it, why not?
I see no inconsistency - yes, in this situation /reviews should be a list of all reviews in system, but if that makes no sense for your application, then /reviews can just yield a 404 and everything's fine.
Ideally, design of URLs should be decoupled from the rest of the REST API. That means, as far as your URLs are uniquely identifying your resources, they're (from purely theoretical point of view) "well designed".
But API is an interface and it should be treated as such. API is consumed by machines, but those machines are written by people, so in fact, design matters. It's the same reason why to have nice URLs on your blog - there is no technical reason for it, but it improves the experience of users if they want to read, share, remember or understand your URLs (you may say that Google searches for keywords in URLs and so it is a technical reason, but no, it's not - Google's bot is just one of your users - website consumers - and optimization for the bot is just like any other optimization for your users, thus it's interface design).
In case design of your URLs matters (for any reason), then in my opinion the best approach is to keep them simple. As simple, as you can. Your observation is very right - you don't need to mimic hierarchy of your resources or the way you store data in database. Eventually it would only get in your way and in a way of people who want to consume your API.
If a resource is uniquely identified within a collection by an ID, then design your URLs just /collection/{id}. Look how Facebook does it - majority of its API does exactly this. Structure of their URLs is pretty flat.
There doesn't even need to be a /collection resource for listing all existing objects. You can have them linked only from places, where it makes sense, like /products/123/reviews, where you can list links pointing to /reviews/{id}.
Why I think complicated URLs are bad?
Relations between resources are graphs and you can't put graphs to URLs
Putting other IDs and hierarchies into URLs makes things more complicated for no reason. Usually, hierarchies are not so simple in APIs - relations between resources are more often very complicated graphs, not simple trees. So don't put linking between resources into your URLs - there are better places (hypermedia formats, link headers, or at least linking by ID references) where to put information about relations and those are not limited to one string like URLs, so with them you can define relations better.
You're torturing your consumer by requesting too much parameters
By requiring more information in URL from consumer, you force him to remember all this context and all those IDs or know those values in advance. You require more (unnecessary) input, but in reality, there is no reason for consumer to remember product's ID just to check out one of its reviews.
Evolvability
In case your URLs are not decoupled well, you should really think of what happends if structure of your data changes in time. With simple URLs, nothing really happens. With complicated URLs, every time you change the way your API resources are related, you'll need to change also URLs so they keep up with your structure. And as everyone knows, changing URLs is hard - whether we are talking about web or APIs. Hypermedia somehow solves this, but even without hypermedia you can do at least so little that you keep your URLs light and as change-prone, as it gets.
Your design could look like this
/products/{id} - specific product, links to an endpoint with list of its reviews
/products/{id}/reviews - lists links to endpoints of reviews of the product
/reviews/{id} - specific review, should link to reviewed product and it could even link to the list above, if it seems to be useful for an API consumer
In fact, any of those resources can also link to any other thing in the system, if its useful or if there is a logical connection. Some linking systems (such as hypermedia) make understanding those links easier, because you can specify a rel attribute, which says to consumer where the link is pointing to (self points to itself, next could point to another page, etc.).
Of course, as always, it depends on your specific case. But generally, I'd recommend to keep URLs decoupled and simple. Also, I wouldn't recommend to to try to mirror any complicated relations or hierarchies in URLs.
As long as the URL can uniquely identify the resource, it is correct.
So the approaches in both Q-1) and Q-2) are fine to use and can be mixed. It is like provide different entry points to the same resource.
The answer to the question comes back to your business use-case. If there is no need for more than one entry points, should just stick with one and it will simplify the code.
To Q-3, ‘/reviews’ will mean all reviews. Also you don’t need to support that if there is no business use-case to get all reviews in your system.
Hope this help.
I have to design a database for an advert site.
Until now this is the design i came up with:
Administrator(Id,Name,Password)
Advert(Advert_Id,Title,Description,Category,User,Date_created,Picture,Type)
User(User_Id, Name ,Phone,email,Address)
Category(Cat_id,Cat_Name)
Type(Id,Type_Name)
Picture(Picture_Id,Name)
The administrator refers to to the person that will manage the site.
The type refers to the type of the advert: selling, buying etc.
I must have minimum 5 tables at least 2 one to many relationships and at least one many to many relationship. The problem is that I can't find a many to many relationship that would make sense.
If an advertisement can have more than one category, then advertisements and category would be many to many.
If an ad can have more than one picture and a picture can be used in more than one ad, ads and pictures would be many to many.
However, you have to know the business rules. None of us will.
Like Dan mentioned on the answer, you have to know the Business Rules. It's a project for a class, so the business rules might be flexible, I remember back in college, for example, they would tell us that if a client wanted to have advertisement be of at least one category, but could have up to 3 or 4 different categories, that changes your DB structure a lot.
An advertisement can also have many pictures, not just one. It can even have some videos, and many of them as well. Make sure you clarify well the Business Rules and that you understand them fully, as in a real life situation, that can represent either the success of your project or the failure of it.