So, I am in need to get a daily average of different weather parameters per country.
I'm able to find weather data for different stations within a country, but I would need an average for the complete country. Is there a way to combine the different stations for a country wide average or something like that? Or is there maybe a database available with historical weather data per country?
I need this because i have a dataset which I want to compare to different weather parameters, and my dataset only includes the country as location, not the specific city etc.
I would require data between the year 2012 and 2020, for multiple countries globally.
Kind regards,
Michael
Related
Has anyone ever tried to store sales data in graph database (Neo4J)?
Say product XX, 2000 copies was sold in US in 2016 and 1000 copies sold in UK in 2016. I have sales information for multiple products, in different years, in different countries. I also have sales information also for competitor products.
My problem is this: Sales of a product is specific for a specific country and year. I cannot just connect a product and sales. Would appreciate any ideas. Thanks.
Usually in these cases you create additional node labels for nodes with this specific use.
For example, maybe a model like this:
(:ProductSale{name:'XX', saleYear:2016, amount:2000})-[:SOLD_TO]->(:Country{name:'USA'})
(:Product{name:'XX', description:'foo'})<-[:SALE_OF]-(:ProductSale)
That assumes you have data you want to save for each type of product. If not, you can get rid of the :Product node.
Having a few issues with my database design. I have designed my system like the following image
As you can see it is a pretty basic system to a point. A user can create a supplier by adding supplier details. A user can then add a product and link it to a supplier. Thats the pretty straight forward bit (I hope!). Now I will attach my database design which should hopefully cover what I have mentioned.
So a supplier can have one contact (person within the suppliers company the user of my system will contact) and a supplier can have one to many products.
He is the part I can't figure out. Twice a week, the user of my system will receive stock from all their suppliers. When they receive this stock, they should go into the update stock screen within the application and input the amount of stock they have received for a certain product. I have added a products_stock table which should hopefully put me on my way to cover this aspect (I think it is missing a lot though).
The last screen however is a display of predicted stock. Lets say for instance on the day my products are delivered, I receive 10 units for Product One. I will then manually count the number of units I have left from the last order for Product One (say 2) and update the stock count for Product One to 12.
This means, that really, I only needed 8 units between the two deliveries for product one. The predicted stock screen is supposed to show the predicted stock levels I should place an order for, for a particular product, over a specified time period. So if 8 units was the average stock sold for product one per week, if I wanted to see how many units I should order for product one for a month, it should display about 32 units.
This is not supposed to be a complex system, it should have this manual aspect to it. I have designed the database up until a point, I was hoping I could get some suggestions regarding the products_stock table and how I can handle stock predictions for a specific period of time (if I maybe need additional tables).
Any advice appreciated.
Thanks
Inventory is more like a view and not a table. Inventory is really a series of movements of goods between locations, as well as periodic counts / adjustments.
Inventory is complex. You should play with some inventory software and read some data modeling books.
Use the concepts of Locations (real and virtual) and Movements (a movement should be its own entity).
Item smashes? Move it from its inventory location to the "damaged" location
Item went missing? Move it from inventory to the "ether" location
Found a random Item? Move it from "ether" to inventory
Sold an Item? Move it from inventory to "sold"
Bought an Item? Move it from purchased to inventory
Some other things to keep in mind:
You could sell something, and it's returned, and you put it back in
inventory
You could buy something, but it ain't right, so you send it
back to the seller
You could sell something that you don't own (on
consignment, or not in inventory yet)
You might have something in
inventory that is not currently for sale.
I won't get into the accounting aspects of inventory :)
One possible approach:
Have a separate "stock item" record for each unit received. When it is sold, record the date of sale in this record.
Then if you want to know how many items were sold in a given time range, just count the records with sold dates in that range, like select count(*) from stock_item where product_id=#product and sold_date between #from and #thru. If you need to keep track of items lost to spoilage, theft, whatever, then you might have a status flag of some kind that says whether it's in stock, sold, destroyed, whatever, and also the date of that status.
If the number of units that pass through is large and there's no other reason to keep individual stock records, you could just have "daily sales" records instead, with a date and number sold that day. Same idea.
I'm trying to make the database system point of sale, however I am confused between the entity and product inventory entity. What are the differences between product and inventory?
I know that the inventory should control the amount of product available .... but i have all that in products.
product code
name
description
cost
unit price
Subcategory code
brand code
amount available
Minimum quantity for rehearing
state
tax code
weight
amount wholesales
wholesales price
perishable
due date
creation date
upgrade date
what i should have in inventory? I have researched and according to what I read I need to have the product, the description, the quantity, purchase price, sale price, profit or gain and date of the transactions. But almost everything is in the Products table, what should I do?
A Product is an abstract Good or Service. A Good is the specification of an Asset.
Example "2014 Mazda 3" is a good. A "2014 Mazda 3 with VIN 12345" is an Asset.
A Catalog is the list of products that you want to sell. They don't need to exist yet, or you could be selling them for someone else.
Items Held For Sale are assets that you keep around to sell. These could be consigned (owned by someone else).
Inventory is an accounting concept. It is the dollar value of the items held for sale that you own, plus inbound and outbound goods that you're responsible for, plus any costs associated with holding that inventory.
You can track the value of inventory in a variety of ways such as FIFO and LIFO
I think you can store the inventory in the products table. There will certainly be transaction tables for purchases for the products and sales and even adjusting records (when items get count and the number differs from what's stored in the database), but you can easily work with the stock stored in the production table itself, thus not having to scan the whole database and sum up all purchases and sales and corrections every time (and never being able to delete old transaction data from the database, as that would invalidate the calculations).
However there are reasons to have stock stored in an inventory table instead. For instance if you want to store different statusses, e.g. you have 100 pieces in store plus twenty just arrived and still unchecked. Or you have a store with goods plus a warehouse housing additional stock. Or you have charges (different model numbers for example for a slightly altered product) which you offer as the same product, but still want to know how many old and how many new ones are in stock. And so on.
So make your mind up, if you want to store additional data with product stock, which would result in an 1:n relation instead of 1:1 which you have now.
I'm new to creating cubes, so please be patient.
Here's an example of my data
I have multiple companies, each company has multiple stores.
Sales are each linked to a particular company, with a particular store on a particular date.
ex:5 sales took place for Company A, Store 1, on 5/19/2011
Returns are linked to a particular company on a particular date.
ex: 3 returns took place for Company A on 3/11/2012
Sometimes my users want to see a list of stores, the date, and how many returns took place, and how many sales.
Sometimes they want to see a list of companies, the specific stores, and the number of sales.
I have a table that stores
COMPANY - DATE - STORE- SALES - RETURNS
I end up having the value for returns repeated for each store under a particular COMPANY - DATE pair.
so if I'm writing a query, and I want to find out returns, I just do a
select distinct company, date, returns from mytable
but I am not sure how to this into a cube (using SS BI and Visual Studio).
(I've only made a couple of cubes so far)
Thanks! (also, feel free to point me at appropriate references)
It sounds like Company is an attribute of the Store and should be in the Store dimension rather than the fact table. There may have to be a transformation on returns to convert the Company to a store.
Am I missing anything?
Imagine you're creating a website that allows people to search for rental cars based on price, amongst other things. Some rental cars are more popular at certain times of the year than others, so their price varies based on date. For instance, a car might cost $90/day most of the year except for December & March, when it costs $110/day, and in January & February it costs $130/day. Is it possible to have a calculated field in Solr, so you can search for a car that costs less than $X/day over the duration of your rental? I'm new to Solr, so have absolutely no idea whether this is possible or not - sorry if I'm asking a dumb question.
One possibility that I've come across would be to index the item once for each price, and have start and end dates for each of these. This copes with the price changes, but won't work for rentals that cross price boundaries; for example, a customer might want to rent a car for one week in February and two weeks in March - we'd end up not finding the car in this case.
I'm using Solr 3.5. Is it possible to do this using a FunctionQuery? I've seen some documentation on them, but all the examples I've seen are using them to return a computed value, rather than performing a search on that computed value. If I can't do this using a FunctionQuery, how could I do it?
I think this might be possible:
In your index you can have different types of columns containing the different prices of different seasons. In your query, you need need to use a product on the price during a certain season against the number of days in that season, and sum it to the product on the price during the other season against the number of days in that season. Yes, you'll have to use FunctionQuery. The means of providing how many days falls into which season that you'll probably have to do on the client that is calling the solr web service. Furthermore, you can try to apply a filter query on the result to pick out the amount that the user is willing to pay.