I have a SQL database with tables such as Stores, Users, etc.
Both Store and User, as well as other entities, have an Address.
I am considering creating an Addresses table for all Addresses:
Users
--------
UserId (PK)
AddressId (FK)
Name
Addresses
--------
AddressID (PK)
CountryID (FK) -> I have a table Countries with all Countries
Street
PostalCode
Locality
Region
Latitude
Longitude
When a user is filling the Profile I would have an input to type the address.
I would like to use Google Geocoding API to convert the typed address into its fields and save it into the database including Latitude and Longitude.
https://developers.google.com/maps/documentation/geocoding/start
https://developers.google.com/maps/documentation/javascript/geocoding
I have a few questions:
Is my Address table scheme appropriate for this?
I am planing to use Google Geocoding API so should I store the PlaceId then Google returns on my database?
My main objectives are:
Convert the address typed by the user into address fields and save to database;
By having the Latitude and Longitude of the address type by the user in my database I will be able to search them by location.
Example: Get users of my application in a radius of 20 km of a London address.
Did you thought about to separate the HouseNumber? Some external Services or API's require this. Its easier to concat this fields if required.
There is a geography Datatype for geolocations: https://learn.microsoft.com/en-us/sql/t-sql/spatial-geography/spatial-types-geography?view=sql-server-2017
With this type you can query the Database performantly with some geo functions e.g. distance between two points.
I wont save the Google-API result directly. Use your own required schema.
If you use the geography type you can query with Long/Lat and Distance by radius.
Related
I'm playing around with entity framework and code first approach. The scenario is this:
An user can have multiple companies (each company has an address)
An user can have multiple houses per company (each house has an address)
I'm thinking of two ways I can manage addresses:
Have an Address table with a column for CompanyId and HouseId (for companies addresses only CompanyId will be inserted and for houses both Ids will be inserted.
Have a CompanyAddress and HouseAddress tables with the only difference between them being the FK for CompanyId versus HouseId.
How would you do it? Is there any other, better options?
In EF Core you should use Owned Entity Types for this. In EF 6, use a Complex Type. Both allow you to have an Address type in .NET without having an Address table in your database.
I am working with a SQL Server database that has a customer table in it that contains (among other things) an address column. This column houses the full address (street, city, state, zip) as one long text string. We are looking to convert this information into latitude & longitude coordinates for plotting on a map. I've been looking into using the Geography data type in SQL Server, but I cannot find any definitive information regarding what data actually needs to be entered into the Geography column in the database table.
The question I have: is there a way to use the Geography data type to convert the address string (or any part of it, City, Zip, etc.) into latitude & longitude coordinates?
For what you're looking to do, you'd need latitude and longitude information. The data type doesn't convert addresses inherently, but there are many services that you can use to do that.
I am creating an address dimension for a Snowflake Schema Data Warehouse. I have 75M locations on a source that I want to convert to said schema. I know how to handle Zip->City->County->State dimensions, but if I add street addresses to the location dimension I would have an equal number dimension rows as fact rows.
What I need to know, is where should the street addresses go (123 anywhere St.)? Should it go in the fact table? How do I handle street addresses?
Thanks.
The street address itself should go in a Fact. If it's a Real Estate app I'd imagine there'd be some kind of "Sale Contract Fact" or "Rental Contract Fact" or something similar - the street address would be an attribute of that fact.
In your instance the instance of the address is definitely tied to a single transaction. As you said, the same street address could appear multiple times, but it would be on different Sales Contracts and thus different Fact instances.
Other elements of the address (zipcode, city, state etc) would be dimensionalised as it makes sense to group them for classification.
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.