Write a MySQL trigger that does not allow to change the population of the city, where the city
population is greater than the country population where it belongs ?
Related
I have been asked the above question but i know only its meaning that its the finest level of data. for example, if you have name in fact table, then its detail such email, phone number,etc can be found in dimensions table. I have sample dataset and its area level analysis which i have worked on, Please explain granularity of data based upon this data.
Dataset:
itemid
item
RID
Rname
Area
Time_Availability>70%
6222589
peanut banana
1000
Cafe adda
gachibowli
True
6355784
chocolate fudge
2000
Santosh hotel
Attapur
False
Area level of analysis of restaurant on boarding to a platform
Area
Total Ingested restaurants
Available
items_Available >=5
Gachibowli
5
4
2
Attapur
5
4
2
Thank you
The granularity of a fact table is the minimum set of attributes that will uniquely identify a measure.
For example (and I'm not saying this is a real world example), if you had a sales fact table and there could only be one sale per customer per day then "per customer per day" would be the granularity of that fact table. You might have other dimensions such as the store that the sale occurred in or the country where the transaction took place - but these would not affect the granularity if you could still only have one sale per customer per day, regardless of which store or country that transaction took place in
I need help on designing database table for online store. Here is my class diagram :
So I wonder is there anything wrong with my tables? Because it all seems separated. For example, this is how my online store works. First, needy resident creates product which link the Store needy resident table to Product table. Then, when customer order product, the information of needy resident would be pass along from product table to ordered product table. After that, I check for payment. If the ordered product status is paid, the ordered product price would be pass to Payment table and from the Payment table, I can update my Store needy resident's sales amount. It's very complicated and I am quite blur of it also.
So my question is, can somebody please help me check if my class diagram got some error for linking?
Thanks in advance.
I'm building a database that contains for each customer's purchase
Product Name
Product Manufacturer
Store
Date
Buyer's name
Buyer company
Some data such as product name, manufacturer, shop, buyer's name and the buyer's company back on themselves at the time.
Is it better to build them in separate tables and in the primary table to keep their indexes?
On the one hand it saves space on the server
On the other hand it overloads the server and requires more work
I would keep buyer information and product information in separate tables. There is no reason to store this information more then once.
In addition you could use a (relation like) table with buyer id, serialized array of product id's and date of the purchase.
buyer_id | {"prod1_id","prod2_id",...} | date
This way you get a table with all purchases that you can get whenever you want. This will increase the calls to the database but save on the storage.
Hope it makes sense to you.
I want to try and do a geocoding application and access data stored in a SQLite database. A postcode, town or city will be supplied, and I want to return the long/lat. I want it to be screaming fast but I'm unsure about how to organise the data in the DB.
Here is the data im working with:
Town, City, Postcode, Country, Longitude, Latitude
This may be simple but im new to this, I would benefit from some advice.
People will mis-spell all of the things that you propose using as your search criteria. So, do not use strings for Town, City, Postcode, and Country in this database table.
A good first step would be to use an Id, with the Id looked up in a separate table (e.g. the Towns table). A user could then lookup Latitude and Longitude using a combination of Id's. If one or more Ids are omitted, multiple results could be returned. For example, if they only supply the Id for the Postcode and Country, that will match multiple Cities/Towns.
A more efficient method of looking up specifically Latitude and Longitude would be to assign a specific place Id to each entry in the table that holds your Latitude and Longitude
PlaceId Latitude Longitude
Allow the user to lookup the PlaceId separately (by using a combination of Town, City, Postcode, Country and pick from among multiple return values to get a specific Place). Use that PlaceId to lookup Latitude and Longitude.
I'm building a huge database of IP addresses with their geographic location attached (country, city, ect).
Right now, I'm using this simple database structure:
id || ip_addr || country || city ||
I've already starting building it, and I've got almost 1 million records, already. The thing is, lots of addresses have the same country attached and fetching from the database is becoming really slow.
I was thinking, if I do this:
countryTable:
countryID || countryName ||
cityTable:
cityID || cityName || countryID (for what country the city is in) ||
and then, ipTable:
id || ip_addr || countryID || cityID
Would it make fetching any faster?
Is this method more efficient (does it have any other benefits)? Or should I just stick to what I have already?
Yes, moving countries and cities to a separate table is actually a normalization and is a very good step. I would go even further with normalization: a city is located in a country, which means knowing a city you also always know the country. Thus try this:
id || ip_addr || cityID
cityTable:
id || cityName || countryID
countryTable:
countryID || countryName
An extra reference to the country in IP table is unnecessary. Note that this design is not problematic when several cities have the same name like Warsaw (Poland), Warsaw (Indiana, US) and a dozen others - there are duplicated names in the database but ids are different - and you identify cities by id - happening to point to the same name (but in different country).
However I don't understand why you have a separate id column when unique ip_addr exists (providing that a single IP has only one address attached)?
ip_addr (ID) || cityID
Remember that IP address can and should be represented as a number (some databases have built-in database for that), so such a key is as good as artificial one.
Finally, typically continuous ranges of IPs are assigned to the same area/city/district. You will save a lot of space by assigning a range of IPs to location rather than each and every IP.
Yes, normalization typically improves performance. Although the primary reason for normalization is usually data consistency. However in some cases denormalization actually improves performance. This is done in data warehouses and reporting to reduce the number of joins required to filter and compose the result of a query.
One important part here is that the database gets much smaller and more data fits into RAM.
Another key point to performance is having indexes supporting your typical queries.
If you search by city name you should have an index on cityTable.cityName, etc. This way the database can find your data using an efficient search, just reading a few records, instead of scanning the whole database.