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 4 years ago.
Improve this question
I am currently working on developing a program that stores Quantity as a decimal with four digit places for the very small minority of products that are sold in part (eg 100ml liquid being sold in variable amounts like 1mg-3.5mg).
I dislike this design as it causes problems for the entire program in deciding how to present the quantity and now some problems where there are products which incorrectly have decimal values.
Can you think of a better way to do this?
I'm looking for an alternative to a four decimal place field in the database.
The project uses SQL Server 2005.
Edit. I made this question more generic in order to obtain a larger potential audience
Store the quantity in the smallest amount sold. So if something is sold by the mg, store it that way. That way you don't have to store fractions, and deal with rounding.
Just create a looking table for the product so that you can store the value of how it is stored and displayed, as well as any other meta-data about the size.
In .NET, a System.Decimal is going to be your best option as System.Single and System.Double are not good at representing floating point numbers with accurate representational precision.
Can you provide a small, complete example that demonstrates your problem?
Related
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 4 years ago.
Improve this question
I was recently asked the following question in an interview.
"How would you design a system to keep track of a million items at xyz.com ?
The xyz.com could update the prices maybe 2-3 times a day or once per month, so no guarentee on frequency.
Your system should show accurate prices for >95% of items at any given point of time and aim for 99%.
Also scale for 1billion items etc..
"
I asnwered along the lines of creating a distributed system app that would categorize items by priority (based on historical price fluctuations and 80/20 % rule etc) and do API calls more frequently for these.
But I was not allowed to use API calls.
I suggested scraping html content. (But the website can block my ip for such high load)
I basically want to know the resources that would help me anwering these type of questions. Prefer full length courses (Distributed systems ?) or books rather than quick-fix blogs.
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 7 years ago.
Improve this question
Apologies in advance if this is a stupid question. I've more or less just started learning how to use SQL.
I'm making a website, the website stores main accounts, each having many sub-accounts associated with them. Each sub-account has a few thousand records in various tables associated with it.
My question is to do with the conventional usage of databases. Is it better to use a database per main account with everything associated with it stored in the same place, store everything in one database, or an amalgamation of both?
Some insight would be much appreciated.
Will you need to access more than one of these databases at the same time? If so put them all in one. You will not like the amount of effort and cost 'joining' them back together to do a query. On top of that, every database you have needs to be managed, and should you need to transfer data between them that can get painful as well.
Segregating data by database is a last resort.
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 8 years ago.
Improve this question
We are designing a dimensional model for an IT support business. There are cases (some call them tickets or incidents) with different statuses (feels like an SCD type II dimension)
We also need to consider the count of cases and SLA time duration as measures.
Before going into detailed design, I reviewed Kimbal's data warehousing toolkit but couldn't find a matching business for our project. Are there any references for a dimensional model for this type of business
From your limited information it sounds like you want to model as an accumulating snapshot fact (as well as a transaction table). See Insurance claim processing pipeline in Kimbal's The Data Warehouse Toolkit.
It would only be a Type II SCD if the dimension entries were being updated, which in your described case they are not (you are updating the Fact table)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In the case of payment gateways, if the gateway is US-based and can only charge in dollars, but can charge foreign debit/credit cards, and you want to act on countries where the currency is not USD, and you can't/do not want to apply for a local payment gateway, what could you do, programming-wise?
I was thinking about converting the amount in USD to the the specific currency. Problem is:
I don't know where to get real-time accurate exchange-rate data
Not sure if I get the data from somewhere, if the client's card processor will actually charge that exact price
Do you guys know any best-practices for that? I think another way would be to just charge in dollars, and then let the client know that approximate amount in his/her local currency, but again, I'm not sure where to get an updated currency conversion.
Does any of you have gone through a similar scenario?
PS.: Paypal is not an option.
Any hints appreciated!
Currency conversion takes place by your customer's bank, so there's unfortunately no central market through which you can even make estimates.
There are some APIs that you can use to make an estimate, though it's mostly just a guess. If you use one of these, I would make sure to make it clear to your customers that the price may vary depending on their bank.
Overall, I've found the best practice is just to display your prices in the supported currency (e.g., USD) and mention to your customers that it might vary. As we continue to expand internationally, you can take advantage of our local currency offerings to make more exact charges.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
There are several posts on SO that point to sources for downloading historical stock quotes, but these are all for currently listed symbols. The resulting dataset suffers from survivorship bias. Is there any source of all historical data, including delisted companies, preferably for free/cheap? I've found a few sources, but they're usually hundreds of dollars or more, require installing using some Windows client software, or just are on sketchy-looking websites. (End-of-day data is fine - I'm sure asking for intraday bid/ask is too much.)
Where do these data resellers in turn get their data from? What is the original source archive of data? (Some of these datasets date back to the '50s, so I don't think the answer is "they just record it themselves.") Do they cut deals with exchanges / do the exchanges have/sell this? Does the data exist in any public records? Thanks!
Norgate Investor Services is the cheapest I've found, but it will run you hundreds of dollars ( but less than 1000 ). Their source is Standard & Poors.
QuantQuote has survivorship bias free historical stock data, but they only offer it in minute/second/tick resolution, and it costs $$. They also have free daily resolution data of the S&P500. It's too bad Yahoo doesn't keep stock data around after a stock gets delisted.