I'm working on this kind of data structure :
Now, say I have to search for products that are < 90 EUR, it should only returns the product "item2". On the other hand, if I search for products that are == 100 EUR, I should only returns the product "item1".
I have 60 000 products and 16 currencies, so I just can't convert all products in all currencies on a daily basis (as the currency rates updates daily) only to be able to perform this search.
I have 2 questions :
is this use case a good fit for a Postgres function ? Is there any other good and sustainable solution if not ?
if a postgres function is the solution. Given that I'm using Ruby on Rails (4.2) and the search requests (on products sizes, colors etc...) are chained using ActiveRecord : is the call to the DB function still chainable and usable in AR ?
Thanks for your help
Using a function for this is a terrible idea, because performance will suffer greatly: the exchange rates will change over time, rendering your indexes useless.
Further, it's a terrible idea to store a single price per item. Thing psychological prices and tax considerations: if something is €99.99 including VAT in the Eurozone, it'll probably make sense to sell it for $99.99 plus sales tax in the US. No amount of exchange rate manipulation using functions or other will change that. (Compare the prices of Apple in the US, in France, in the UK, etc.).
For each item, associate a price in Euros, one in Dollars, etc. -- each with a currency_id, and have the exchange rates reside in a separate table. Or create some kind of price-list table in which you associate prices based on currency (e.g. €99 = $99) to a price_id, and associate the products (it's actually the SKU, btw) to their corresponding price_id.
You can fill this data in semi-automatically using an exchange rate table, and periodically update them using one as well. But really: do reserve the ability to manually set prices, make sure you mark prices as including or excluding tax. And when it comes to taxes, don't forget that tax rates are different from a place to the next and from a product to the next.
For the record, I ended up creating a new column "price_eur" in the "products" table where I convert each price to EUR whatever is the original currency. Doing so I can perform a consistent search based on this price_eur column.
I just wanted to know if there was an alternative solution but looks like there is no other simple way...
Related
I've been using the Android billing client for a while now and always display the prices using getPriceAmountInMicros() from the SkuDetails object returned from the billing client.
Often we get complains from some of the customers that the price we display is not the same price they're paying. I've always assumed this is due to local taxes and that the Google play Store doesn't return the prices with local taxes included.
However, going to the documentation of getPriceAmountInMicros() things start to get a bit fuzzy. In particular this section:
This value represents the localized, rounded price for a particular currency.
What is a "localized price"? Is this including taxes? I cannot find any explicit place where it says this includes taxes or that it doesn't. By contrast the documentation for getPrice() explicitly states that the price does not include taxes.
Looking into a completely different resource, yet connected to a sku, one can see the same method - getPriceAmountInMicros(). In this method, it's explicitly stated that the price does not include taxes. It would seem odd to me that they would choose to name the method in a SkyDetails object the same, but have different semantics. Nevertheless, I want to be sure and would highly appreciate your help!
Thanks for pointing this out.
Because the QPS of computing taxes during skuDetails queries would be high, our servers defer tax computation to the purchase flow. So unless you need getPriceAmountMicros() for, say, refunds; you should simply use getPrice().
We recently started to work in a big project and we decided to use MongoDB as a DDBB solution.
We wrote a lot of code, but the project has started to grow and we found out that we're trying to use joins instead of doing it the NoSQLway, which denotes a bad DDBB design.
What I'm trying to ask here is a good design for our project, which, at this point consists of the following:
More than 12.000 Products
More than 2.000 Sellers
Every seller should have its own private area that will allow to create a product catalog based on the +12.000 "products template list".
The seller should be able to set the price, stock and offers, which will then be reflected only in his public product listing. The template list of products will remain unchanged.
Currently we have two collections. One for the products (which holds the general product information, like name, description, photos, etc...) and one collection in which we store documents that contain the ID of the product from the first collection, an ID that is related to the seller and the stock, price and offers values.
We are using aggregate with $lookup to "emulate" SQL's left join to merge the two collections, but the process is not scaling as we'd like it to and we're hitting serious performance issues.
We're aware that using joins is not the way to go in NoSQL. What should we do? How should we refactor our DDBB design? Should we embed the prices, offers and stock for each seller in each document?
The decision of using "Embedded documents" or "Joins among two or more different collections" should depend on how you are going to retrieve the data.If every time,while fetching product, you are going to fetch sellers,then it makes sense to make it an embedded document instead of different collections.But if you will be planning to fetch these two entities separately, then only option you are left with is to use Join.
I'm working with a startup building an exchange platform where commodities from an Item collection with around 50,000 documents can be bought and sold by users, who create buy and sell bids for these items.
For our "buy it now"/"sell it now" features, it's required to calculate the best buy and sell bids for an item. Currently we are calculating these on the fly with an index in the UserBids collection on the buy and sell bids field (for a given Item document, let's say with ID 1234, we'll find all UserBids for item 1234 and get the maximum buy bid and minimum sell bid). This is used to present every user with the best price they can buy/sell an item instantly at, and requires a lot of queries on the UserBids collection, but prevents having to update a canonical 'best' price for each item.
I'm wondering if it would be more performant for the Item schema to have a MaxBuy and MinSell field. This would require the MaxBuy and MinSell fields for an Item document to receive an update every time a user enters a new bid, using something like Items.update({id: itemId, $or: [{maxBuy: {$lt: currentBuyBid}}, {maxBuy: null}]}). We would still have to perform the same number of queries to show a user the best price, but the queries wouldn't require an aggregation, and as the exchange grows, we expect the UserBids collection to grow much more than the Items collection (which should remain relatively the same size)
Bids may be added/modified regularly, but we expect the volume of users checking best buy/sell prices to be about 10-100 times greater. Is there a good way to evaluate which one of these approaches would be best?
This mostly depends on which use-case is more frequent and performance-critical:
a user placing a bid which would trigger a recalculation of said fields
someone checks the price
When you assume that the latter use-case is more frequent, this is the one you should optimize for.
In Opencart, I have a product which you select colors of.
Basically the pricing should be: Each additional printing color costs a flat rate of $50 + $0.25 for each.
So if a person were ordering 1000 items, with 2 colors, the cost would need to be BASECOST + $100($50x2) + $250(1000x$.25)
Right now I'm only able to set up the cost for each product. Since people are going to be both ordering large and huge quantities, there's no easy way to build it into the each price.
I could have sworn I saw a free extension awhile ago that allowed you to set both a flat price for an option, and a price for each on the quantity. Trying searching everything I could think of, but the only thing that I could find is for shipping (we already have a pretty complex setup for the shipping, so can't mess with that).
Has anyone came across a solution, or simple extension for this problem. Seems like a simple thing, but still can't find a solution for the life of me.
Thanks!
The easiest way I can see to do this would be to have fixed costs for certain price breaks which can be done through the Discount tab of each product, and can even be set based on customer group if you have wholesale as well as regular customers or other customer groups
I need to get the index of a exchange like NASDAQ rather than the price of a specific stock in that exchange. I suppose that Finance::Quote will come to the rescue , but after a quick go-through of the document, I find it the way one can use the module for query is like:
%info = $q->fetch("australia","CML")
which means both the exchange and the stock should be specified in the query. then the question is: does the index itself can be treated as a stock and has a symbol name which can be used in the query?
Of course, if you have other way can meet my needs rather than using Finance::Quote, please feel free to write down your solution.
The problem with your question is that you are assuming that there is just one index for a particular exchange. Whilst there may well be a particular index that is dominant (eg. for stocks primarily traded on the London Stock Exchange, the FTSE 100 might be considered the main index; similarly for the NYSE it would be the Dow Jones Industrial Average) other exchanges may have a less clear leader in their collection of associated indicies (eg. for the Australian Stock Exchange, the S&P/ASX 200 and the All Ordinaries index are both frequently quoted side-by-side in the evening broadcast news).
Symbology of stocks, indicies, option chains, futures, etc is quite a complicated field in financial IT. Many of the symbology standards are backed by a data vendor (eg. Reuters, Bloomberg) and use of their standards requires a commercial license. On the other hand there are other efforts aiming to make symbology more open (Bloomberg themselves are behind one of these efforts).
I'm not familiar with the data sources of the Finance::Quote package you reference, but if you are serious about accessing market data (ie. prepared to pay for it) but don't need the cost/complexity/speed of a solution from Reuters, Bloomberg, etc, you could do alot worse than check out what Xignite offers in the way of market data accessible via web services.
the symbol for the nasdaq composite is "^IXIC". For nyse composite it's "^NYA".
each quote provider might have a different syntax though.