A product can have distinctive sorts of attributes, and they can change with regard to items, such as a car can have taking after qualities: {cost, colour, price} and chair can have : {cost, width, profundity, stature}. Product attributes are organized in a progressive bunch structure, where a product attribute group can contain one or a few product attributes and/or attributes. Group can contain one or a more Product Attributes and/or Product Attribute Groups.
Write the code required to handle the over portrayed items and a print work that prints the information in such a way that it is evident which properties have a place to which item and which quality gather in case any.
Java : I have a large list of products object from MySQL DB. Now this has to be sorted and listed based on various rules.
For example:
The list has to be sorted based on the following conditions
Location Id of user and product has to be matched and this should the top priority in the listing. (Changes depending on the user location)
Featured product has to be take the next priority.
Any new preference in future should be accommodated as next in the list
Currently this is achieved by monolithic way by fetching objects from DB based on different conditions nd appending the list, but maintaining the redundancy (same products fall under multiple categories has to be managed) and when the list grow relatively large this will not be scalable.
I'm looking for an algorithmic way or any best approach
To keep it short I want to list products like how Amazon or any shopping platform lists based on different business rules depending on the user.
I need to implement drop downs for country, state and district.
For getting a list of state, I don't want to make a query to the DB.
i.e. When the server starts up, all the list of countries, states and districts should be loaded on to the memory using static class or methods. From there I should be able to fetch list of states and list of districts. For example, from one district, I should be able to find out from which state and which country it belongs to.
Every country, state and district, will have an id, title, shortcode.
My prime intention is to reduce the number of query request to the DB serve.
I have a Database storing details of products which are taken from many sites, and gathered through the individual sites API's. When I call the feed, the details are stored in a database table.
The problem I'm having is that because the exact same product is listed on many sites by the seller I end up having duplicate items in my database, and then when I display them on a web page there are many duplicates.
The problem is that the item doesn't have any obvious unique identifier, it has specific details of the item (of which there could be many), and then a description of the item from the seller.
What I would like is for the item to show up once, and then give the user details of where else the item is listed.
How would I identify the duplicates that have come in, without slowing down the entire database? How would I also then pick one advert from all the duplicates, and then store what other sites the advert is displayed on.
Thanks for any help.
The problem is two-fold, and both are on your side. When you figure out how to deal with that, writing the code into a program (Java or SQL will be easy). I'll name them first and then identify the solutions.
For some unknown reason, you have assumed that collecting product descriptions from mulitple sites will not collect the same product.
You are used to the common and nonsensical Id column, which is fine when you are working with spreadsheets prototyping functionality; but it is nowhere near what is required for a database or Development-level functionality. Your users (or boss) have naturally expected database capability from the database, and you did not provide any. (And no, it does not require fuzzy string logic or magic of any kind.)
Solution
This is a condensed version of the IDEF1X Standard for modelling Relational Databases; the portion re Identifiers.
You need to think in database terms, and think about the database tables you need to perform your function, which means you are not allowed to use an auto-increment Id column. That column gives a spreadsheet a RowId, but it does not imply anything about the content of the table, or the columns that identify a product.
And you cannot simply rip data off another website, you need to think about what your website requires for products. What does your company understand a product to be, and how does it identify a product ?
Identify all the columns and datatypes for the columns.
Identify which columns are mandatory and which are optional.
Identify which are strong Identifiers. Eg. Manufacturer and Model; the short Product Name, not the long Description (or may be for your company, the long description is an Identifier). Work with your users, and work that out.
You will find you actually have a small cluster of tables around Product, such as Manufacturer, ProductType, perhaps Vendor, etc.
Organise those tables, and Normalise them, so that you are not duplicating data.
Make sure you treat those Identifiers with a bit of respect. Choose which will be unique. Those are Candidate Keys. You need at least one per table, and there will be more than one in Product. All the Identifiers that will be searched on will need to be indexed (Unique or not). Note that Unique Indices cannot be Nullable, so you cannot choose an optional column.
What makes a single Unique Identifier for Product may not be a single column. That's ok, we can evaluate multiple columns for keys in databases; they are called Compound Keys.
Take the best, most stable (one which will not change) Unique Identifier, one of the Candidate Keys, and make that the Primary Key.
If, and only if, the Unique Identifier, the Primary Key, which may be a Compound Key, is very long, and therefore unsuitable for a Primary Key, which is migrated to the child tables, then add a Surrogate Key. That will be the Id column. Note that that is an additional column and additional Index. It is not a substitute for the Identifiers of Product, the Candidate Keys; they cannot be removed.
So far we have a Product database on your companies side of the web, that is meaningful to it. Now we are in a position to evaluate products from the other side of the web; and when we do, we have a framework on our side that is strong, against which we can measure the rubbish that we get from the other side of the web.
Feeds
You need a WebSite table to manage the feeds.
There will be an Associative table (many-to-many) between Product and WebSite. Let's call it ProductSite. It will contain only our ProductId, and the WebSiteCode. It may containPrice`. The contents are valid for a single feed cycle.
Load each feed into a staging database or schema, an incoming ProductIn table, maybe one per source website. This is just the flat file from the external source. Add a column IsValid and set the Default to true.
Then write some SQL that compares that ProductIn table, with its loose and floppy contents, with our Product table with its strong Identifiers.
The way I would do it is, several waves of separate checks, each marking the rows that fail, with IsValid to false. At the end Insert the IsValid rows into our ProductSite.
You might be lucky, and get away with an optimistic approach. That is, as long as you find a match on a few important columns, the match is valid. (reverse the Default and update of the IsValid boolean).
This is the proc that will require some back-and-forth work, until it settles down. That is why you need to work with your users re the Indentifiers. The goal is to exclude no external products, but your starting point will exclude many. That will include going back to our Product table and improving the content (values in the rows) of the Identifiers, and other relevant columns that you use to identify matching rows.
Repeat for each WebSite.
Now populate our website from our Product table, using information that we are confident about, and show which sites have the product for sale from ProductSite.
I don't think this is a code or database problem (yet). You say:
The problem is that the item doesn't have any obvious unique identifier
You need to work out what that uniqeness is before you can ask a computer to do that for you. It sounds like you need some sort of fuzzy, string similarity algorithm.
Some examples of data that you consider duplicates might help.
I am authoring a javabean and would like to know if it should include properties to set values obtained from a sql join?
Say I have database tables for Products and Orders. These are also my java bean names.
Now I want to display a list of all products but in addition to all the product properties, I want to have columns to display last purchase date and last purchased by
My db query to get the product list would need to do joins to gather the additional info. It does not seem correct to have setters and getters for `last purchase date and last purchased by' in Product.java model. I may want to have a 3rd column so constantly adding new columns to my bean doesn't make sense.
How do you go about this? I seem to encounter this when needing to display lists of models in my view.
Have a Map in Product. Upon firing the sql, store hte results of the join as key value pair in the Map. K=lastpurchasedby(columnName) and V= the value
So no need to add individual attributes. They all come in key-value pairs.