From reviewing the documentation, adding synonyms seems really straight forward.
For my site however, we have such a diverse mix of product categories that we need synonyms to be based on category in some cases.
Example:
A search for "x360" is a synonym for "xobx 360" in the category "game consoles"
A search for "x360" is a model number in the category "laptops"
Therefore we would want the synonym to be activated in the "games consoles" category only.
Based on what you described even if the query x360 matches the synonym xbox 360 when you are in the category laptop (so with the facetFilter="category:laptop") it doesn't matter, because at the end there shouldn't be any record matching with xbox 360 within that category. So the engine will then pass on other matches and match the query x360 with one of the laptop reference.
Related
I have been asked by a customer to develop a "product configurator", and i need some inputs on how to handle the DB part of the project.
Each product can have a subset of different precreated attributes.
The minimum is 1 attribute, but there is no maximum.
Some attributes have dependencies/relationships with other attributes.
Eg. If the product is a chair, you need to choose the material (wood, plastic, metal), and you need to choose which type of legs the chair shoud have.
If the Product is a cabinet, you still need to choose a material, but instead of legs there will be different doors to choose from etc.
Each of these attributes might have subattributes. Eg. the door has a color, a size and a doorhandle.
Then the door handle has a material, a type and so on.
This ultimatly ends up in a multi-layered attribute-tree.
By itself this isnt too complicated to code, however the customer wants to be able to manage (Create, update and delete) all products, attributes and relationships between attributes, within the webapp.
So coding the relationship-part isn't a viable solution.
I have gone with a EAV model to facilitate the "potential unlimited" amount of attributes each product can have.
But i am struggling to figure out how to go about the "attribute relationships".
A simplified version of my DB design looks like this:
If each product could subscribe to groups of attributes that is legal. Then each attribute belongs to a group like "wood group".
Then the user could set the groups of attributes against a product that should need to be answered to configure a product.
With regards managing a tree, you could use a column type of hierarchyid . Or construct an outline string as key field.
An outline for example
1.
1.1.
1.1.1.
1.2.
2.
2.1.
The Best Buy Search allows to search products specifying a criterion on details.name and details.value fields.
http://api.remix.bestbuy.com/v1/products(details.name="Processor Speed" & details.value="2.4Ghz")?apiKey=YOURKEY
However details is a collection. The query above actually returns all products has a detail entry named "processor" and a detail entry whose value is "2.4Ghz" but not necessarily in the same details entry. Is there a way to create a query that will return only products for which those value and name are for the same details entry ?
Unfortunately there is no way to do this unless the particular detail you are interested in has been exposed as a top level attribute (processor speed has not). To accomplish this you will need to run your query as you have described, and then comb through the results and remove the irrelevant products in your own code.
The product page offers two sizes for each product. For example Coca-Cola 1liter and Coca-Cola 0.5liter. Above is the productname "Coca-Cola" and beneath of that comes the "Coca-Cola" description. Is it possible to insert both sizes into the schema.org markup or do i have to choose one productsize and just ingnore the other size/price?
I assume that you refer to Thing > Product
Product is defined as:
anything that is made available for sale — for example, a pair of shoes, a concert ticket, or a car.
In e-commerce world anything that is made available for sale is called SKU (stock-keeping unit) and product is usually a container for SKUs (I said usually, as different platforms can have different terms or data structures).
So from your description I see that your system has a product which is "A bottle of Coca-Cola" with two SKUs:
1-litter bottle of Coca-Cola
0.5-litter bottle of Coca-Cola
I would use information of the SKUs for schema.org Product.
Some schema.org attributes comes from parent product (in your case A bottle of Coca-Cola) e.g. url (assuming you have two SKUs: 1-litter and 0.5-litter on the same page) or description (assuming you have generic description coming from product). But some other attributes like weight (or size / price) will be specific for each bottle. There is also sku attribute which usually refers to your SKU number.
As a side note, you can find similar challenge when building, say, Google Product Feed, and the similar approach will work perfectly fine.
I hope that will help.
Don't laugh but I'm a Lotus Notes (non-relational database!) developer trying to work with SQL and, although I have the basic concepts nailed, I'm stuck on something I'd consider to be "advanced".
Imagine a user reaches an online checkout having added a set of products to their basket. I need to apply promotions to the basket.
These promotions look at the items in the basket and add "points" for any combination that matches a pre-defined "bundle". The promotions also need to be able to target users in specific countries (information gained at point of registration) and other personal details.
The promotions are entered and maintained by the site admin team and need to be as flexible as possible. So they can reward people for things like "Buy X products of type Y and get 50% extra points" or "3 or more XE-123s and get 500 points added" etc.
Right now I'm looking for general direction. How should I store the criteria that matches the items in a basket to any of the running promotions? Would one big Stored Procedure do or should the C# code that builds the basket loop through all promotions and see which fit?
Right now I don't even have a table schema. Just the knowledge of how it should work and little idea where to start.
Jake
My suggestion is to not use SQL for this sort of business logic.
The database is a good place to keep information about products like whether they are type Y or type X. This keeps the database design pretty straightforward.
What you mention about C# seems like a better direction. There is a lot of searchable information about 3-tier architecture that can help explain the benefits of this strategy well.
'As flexible as possible' is a red flag (IMHO). I'd try to nail that down to:
"Fixed-point and/or percentage (of total basket / bundle points) bonus (three columns in a helper table)
When the basket contains a combination that matches a pre-defined 'bundle', where 'bundle' is contained in a helper table, with multiply rows, with a bundleID and a row for each item in the bundle, containing at least ItemID and Quantity.
And no other kinds of reward possible. This to keep the project / requirement manageable.
Then have a SP which checks for the presence of bundles within the basket and applies relevant promotions (as stored in the first helper table).
Also make sure you know the requirement whether 1 or multiple promotions are possible.
The are some articles are written in several parts,
for example, I got those articles from IBM developer works:
Distributed data processing with
Hadoop, Part 1:Getting started
Distributed data processing with
Hadoop, Part 2:Going further
Distributed data processing with
Hadoop, Part 3: Application
development
I will index those three articles separately. And some one search certain keywords, it is possible the part3 is on the top of hit whle part1 is on the 32th. Therefor, if I list results page by page, the part1 and part3 will display on different page.
How can I make sure the hitted documents in the same series displayed together?
I guess in SQL, we can use "group by".
I believe what you are asking for is Field Collapsing, which is currently a trunk feature in Solr, and will be incorporated into the next Solr version.
If you want to roll your own, One possible way to do this is:
Add a "series id" field to each document that is a member of a series. You will have to ensure that this gets incremented for every new series.
Make an initial query to Lucene, and get a hit list.
For each hit, check to see if it has a series id; If it does, make another query by the series id in order to retrieve all the members of the series.
An alternative is to store the ids of all the series members in a field inside each member's document.