I want to calculate distance between two zip codes before inserting the data to database .basically i have a these tables
zip code table
| zipcode | lat | long |
01230 60.1756 23.12
01240 60.1756 25.25
customer table
| name | zip code |
foo 01230
sales man table
| name | zip code | workingdistanceinkm
foo 01240 200
foo1 01230 100
What I want to do is calculate the distance between the sales mans and the customer if it is any of the salesman working area before the data of the customer is inserted to customer table .
MY approach was to calculate the distance between a customer and every sales man that is in the sales man table. But this makes a lot of queries for example if I have 1000 sales man it means I am calculating the distance between the new customer data to be inserted with those every one of the 1000 salesmen.
I am wondering if it's possible to write one query to do the same task.
Have a look at
www.zipcodeworld.com/samples/distance.php.html
note that distance calculations between zipcodes are not always the actual representations of the distance. This is just the distance of an imaginary straight line between the two points. But in reality it is longer
Below URL helped me a lot. Please check "Finding Locations with MySQL" section. Thanks.
https://developers.google.com/maps/articles/phpsqlsearch_v3
Related
I have two tables and I would like to compare one value to see if it is less than another value.
Considering the two example tables I want to make a SELECT statement that would tell me, given my wallet amount which items I could afford. How do I say:
SELECT product FROM Store WHERE price < amount
The above obviously does not work I have searched everywhere.
Wallet:
name amount
--------------
Mymoney 20
Store:
product | price
-----------------------
Apple | 3
Orange | 4
Steak | 21
As you are working with 2 diferent tables, you should use some kind of join like:
select product from Store inner join Wallet on price <= Mymoney
sqlFiddle:
http://sqlfiddle.com/#!9/b431a2/4
I want to store large amount of cryptocurrencies data in db. Then I want to show nice javascript price graphs with historical prices on webpage.
Problem is that I am not sure what database design is best for this problem, I was thinking about Mysql DB, but maybe NOSQL db are better in this case, I don’t know.
What I need:
I need to track at least 100 crypto currencies with historical and
current prices and other stock information like volume etc…
I am going to insert new data every 10 minutes for each crypto ((6
records / hour * 24h * 365 days) * 100 for each crypto = 5 256 000
new records per year )
I need to query various time ranges for each coin to draw graph on webpage.
My idea:
I came with this solution but I need to know if this is ok or I am completely wrong and naive.
In this case I would have 2 tables, first parent table where I would store all necessary info about coins, children table where would be all prices, but this child table would have to contain a huge amount of data, which is worrying me.
My table structure example:
tbl_coin_detail:
id. |Tick_name | Name |Algorithm |Icon
1 | BTC |Bitcoin |SHA256 |path/to/img
2 | ETH |Ethereum |Ethash |path/to/img
.
.
.
tbl_prices:
id | price_USD | price_EUR | datetime | Volume_Day_BTC | FK_coin
1 | 6537.2 | 5 632,28 | 2018-07-01 15:00:00 | 62121.7348556964 | 1
2 | 466.89 | 401.51 | 2018-07-01 15:01:00 | 156373.79481106618 | 2
.
.
.
Another idea is to make separate table for each coin prices, that would mean 100 tables with all historical and current prices and stock info instead of one huge table.
I am really not sure here, what is better, all prices in one table are good for simple querying, but I guess it can be huge performance bottleneck, make queries from separated table will be worse for querying, because I will need to write query for each table but it can help with performance.
Can you point me to right direction how to solve this? SQL DB or NOSQL what is better?
Thank you in advance.
MySQL recommendations...
You have Volume_Day_BTC, yet you say "6 records/hour" -- is the record daily or more fine grained.
The volume of data is not that great, but it will be beneficial to shrink the datatypes before you get started.
id is unnecessary; use PRIMARY KEY(coin, datetime) instead.
Think carefully about the datatype for prices and volumes. At one extreme is space (hence, somewhat, speed); at the other, precision.
DOUBLE -- 8 bytes, about 16 significant digits, large range
DECIMAL(17, 11) -- 8 bytes, limited to $1M and 11 decimal places (not enough?)
DECIMAL(26, 13) -- 12 bytes, maybe big enough?
etc.
Would it be OK to summarize data over, say, one month to save space? Hourly or daily avg/hi/low, etc. This would be very useful for speeding up fetching data for graphing.
In particular, I recommend keeping a Summary table by coin+day with volume, price, etc. Consider using FLOAT (4 bytes, 7 significant digits, sufficient range) as more than good enough for graphing.
So, I am recommending 3 tables:
Coins -- 100 rows with meta info about the currencies.
Prices -- 5M rows/year of details -- unless trimmed (400MB/year)
Summary -- 36500 rows/year for graphing range more than, say, a week. (4MB/yr)
It may be worth it to have an hourly summary table for shorter-range graphs. There is no need to go with weekly or monthly summaries; they can be derived from the daily with sufficient efficiency.
Use InnoDB.
Summary tables
To be honest, that's far from 'huge'. We aren't talking billions of records here, so any properly indexed DB will do just fine.
I'm creating a report that shows how many sq ft my company worked during a time period and what's the cost per sq ft. I have this 2 Datasets
ServiceProviderSqFt
ServiceProviderID
ServiceProviderName
Total
Month
CostSqFt
ServiceProviderID
ServiceProviderName
Cost
So the matrix I created looks like this:
ServiceProvider | Expr(Months) | *Cost Per Sq Foot |
ServiceProvider | Sum(Total) |missing|
So, the word missing is where I'm having problems. I need to put over there the Cost for each provider, so It can looks like this:
Service Provider | Jan | Cost Per Sq Foot
Provider 1 | 250 | 1.10 |
Any thoughts?
Thanks in advanced
If you have to use 2 separate datasets, you can use the Lookup function. There are many resources on that out there. The best option with SSRS is to combine those datasets at the database level as subqueries so that you can work with just the one dataset in the report. Hopefully this points you in the right direction.
Hypothetical database for events happening around the world.
EVENT
event_id | event_name
1 | Great Wall Party
2 | Times Square Dance
3 | Sydney Blowout
PLACE
place_id | place_name
54 | Times Square
55 | Manhattan
56 | New York City
57 | New York State
58 | USA
EVENTPLACE
eventid | placeid
2 | 54
RELATEDPLACES
rel_placeid1 | rel_placeid2
54 | 55
55 | 56
56 | 57
57 | 58
If I display the event, Times Square Dance, I’d like to display all the places that appear up the chain of its associated places via the RELATEDPLACES table (i.e. Times Square, Manhattan, New York City, New York State, USA). Likewise, if I call all events for USA, I’d like the Times Square dance to be listed, given its EVENTPLACE (Times Square) appears at the bottom of the RELATEDPLACES chain of associations starting with USA.
I think I need to create an inner loop within my SQL command so that it keeps performing until there is a break in the chain. So far (using the first of the two above examples) I have:-
SELECT place_nm FROM eventplace
INNER JOIN relatedplaces ON placeid = rel_placeid1
INNER JOIN place ON rel_placeid2 = place_id
[where the loop should begin:
INNER JOIN relatedplaces ON place_id = rel_placeid1
INNER JOIN place ON rel_placeid2 = place_id
end loop]
WHERE eventid = ‘2’;
This is complicated by the fact that I need different table aliases for each loop, which means I can’t state in the opening SELECT statement that I want to be collecting all the place_name data in the same column.
I’m not sure if I what I am trying to achieve is even possible and my current fallback solution is to list all of Times Square’s related places in the RELATEDPLACES table, rather than just the next largest place (Manhattan), but this seemed like the better solution (and would also save database space).
Can anyone suggest the SQL SELECT command I might need to use? Cheers!
Quite an intriguing problem. But the issue is that MySQL currently does not allow for recursive queries. You have two options :
Decided on the level of RelatedEvents upto which you want to dig into, and create a query for the same (using excel or a small C code)
Use a program to generate and execute the queries on the fly; recursively make DB queries from the program. I suggest this is the best option, though requires repeated DB access.
I am trying to get a recipe scaling method in my app which will return some nicer measurements adapted to the amount the use is serving.
For example, the recipe for 6 people calls for 1 cup of flour. If you scale that for one person, 1/6 a cup of flour is 2.5 tablespoons, which is a nicer way of saying it (why search for and dirty a measuring cup when you can just use a spoon?).
So I have in the db a weights table with weight in grams, corresponding measurement and amount.
eg. for flour
amount | measure | grams
----------+-------------+---------
1 | cup | 160
1 | tbsp | 10
1 | pound | 454
in my app (using activerecord preferably) I'm trying to get the best fit measurement for each ingredient in the recipe.
#ingredients = Recipe.select('food_names.name,
ABS(ingredients.grams-weights.grams) as nearest_weight,
weights.amount,
weights.measure'
).joins(
{:ingredients=> :food_name},
{:food_names=> :weights}
).where(
"recipes.recipe_id", :recipe_id
).order(
:nearest_weight
).reverse_order
the nearest_weight searches for the closest match of weights in the database, but I need to find the weight and measure associated with that row, and at the moment, I'm getting all the rows returned.
What I need to do is somehow limit the nearest_weight to one row, and then get that row so I know what the weight and measure are, and I'm hoping I can do that all in one query.