If I have the following tables listed below, would I want to put the AddressTypeID in the Address table or the CompanyAddress table?
COMPANY
CompanyID
COMPANYADDRESS
CompanyAddressID
CompanyID
AddressID
ADDRESS
AddressID
ADDRESSTYPE
AddressTypeID
First, stop to think about whether this is really a many-to-many relationship. Will you ever really assign the exact same address record to more than one company? You may be able to simplify your design by eliminating CompanyAddress and adding a CompanyID column directly to Address.
If this truly is a many-to-many relationship, then to answer your original question, keep the AddressTypeID in Address, not in CompanyAddress, since it should be the same type for every company that uses it.
Related
I have an incorrectly modeled 1:1 relationship between two tables:
Table: Customer
* id (bigint)
* ...
Table: Address
* id
* customer_id (bigint) <--- FOREIGN KEY
* street (varchar)
* ...
The real-world relationship is so that a customer may have one address or not. However, with the current data model, it would be possible to assign multiple addresses to a customer. We do not do this at the moment, so the data could be migrated to this:
Table: Customer
* id (bigint)
* address_id (nullable bigint)
* ...
Is it possible to make this migration in one transaction, using purely SQL code? I would like to avoid an intermediate state where we have both relationships and migrate the customers one-by one. That is the best idea I came up with so far.
What I understood so far is you want to add address_id column in customer table. If there is more than one address for a customer then you might need to select only one address. Here I am considering last address.
update Customer
set address_id=(select max(id) from Address a where a.customer_id=Customer.id)
You can actually leave your data model as is and just add a unique constraint to address:
alter table address unq_address_customer unique (customer_id);
This is not ideal, but it does enforce the unique constraint with minimal changes to the data model.
That said, I would question why you want only one address per customer. Have you considered these situations?
Customers whose "delivery" address and whose "billing" address are different.
Customers who move.
Customers whose address changes although they do not move, say due to postal code reassignments or street name changes.
I have 3 entities
workers
students
addresses
Each worker can have multiple addresses. Each student can have multiple addresses. Each address can be the address of x students and y workers.
My question is, how does the best data modeling look like. Implement the many-to-many relation in only one associative table for everything like so:
ID | Address_ID | Worker_ID | Student_ID
where ID is PK and Worker_ID or Student_ID can be null
or 2 tables like so:
Address_ID | Worker_ID
PK is Address_ID and Worker_ID
and
Address_ID | Student_ID
PK is Address_ID and Student_ID
Which option is the best and maybe why?
Thanks in advance.
First of all: it is not good modeling techniques:
Each address can be the address of x students and y workers
There is no need to specify an Address to two or more Students or Workers. If they have same Address you can repeat the Address. Note that: How many Students and Workers have the same Address?
In this case: Redundancy is better that Complexity.
Secondly: Your first approach is wrong (ID | Address_ID | Worker_ID | Student_ID) and make a Nullification trap in database. Your second approach is better.
Thirdly: I offer third approach.
You have Worker and Student tables. So absolutely these tables have common attributes. So You can make another table named it: Person. Then put all common attributes in it. Then you can relate Person with Address (many-to-many or one-to-many)
In this case there is inheritance between Worker and Person (and Student and Person). To Mapping the inheritance to relational model, you can use one-to-one relationship between Worker and Person (and Student and Person). In these one-to-one relationships, it's better to transfer Person_ID to Worker (and Person_ID to Student).
I have some questions.
Why you decided to make an Address table?
How many searches in you system are based on Address fields?
You can use Address as a String field. In database design we change a multi-field field to table in some conditions. The important condition is searching the fields are so much.
For example in Post System or Telephone or Address Finding System, not in regular systems.
I have country, region, county, town data and I'm currently deciding between 2 schema designs (if there's a better one, do tell).
I first thought
Country
Id
Name
Region
Id
CountryId
Name
County
Id
RegionId
Name
Town
Id
CountyId
Name
Does the job however to get all towns in a country you have to 3 inner joins to do the filtering. I guess this could be ok but potentially expensive?
The other design was:
Country
Id
Name
Region
Id
Name
County
Id
Name
Town
Id
CountryId
RegionId
CountyId
Name
This way all hierarchical data so to speak is at the bottom and you can go back up however if you want all regions in a country you're a bit screwed which makes we wonder whether the first design is best.
What do you think is the best schema design?
The best database design depends on how the data is being used.
If this is pretty static data that will all be updated at one time and external references are all to towns, then I would probably go for a denormalized dimension. That is, store the information all in one row:
Town Id
Town name
County name
Region name
Country name
Under the above scenario, the ids for county, region, and country are not necessary (by assumption).
If the data is being provided as separate tables with separate ids, and these tables can be updated independently or row-by-row, then a separate table for each makes sense. Putting all the ids into the towns table may or may not be a good idea. You will have to verify and maintain the hierarchies when data is inserted and updated.
If ids for each level are necessary for your, then you should have appropriate table structure for declaring foreign key constraints. But, this can get complicated. Will an external entity have a "geography" attribute that can be at any level? Will an external always know what level it is going to refer to as?
In other words, you need to know how the data is going to be used in order to define an appropriate data model.
I am working on database design so want to understand the pros & cons of having a separate table only for relationship.
It should be like:
Customer [Customer Detail] (CustomerID AS PK)
Address [Address Detail] (AddressID as PK)
CustomerAddress [CustomerID FK, AddressID FK]
Or
Customer [Customer Detail] (CustomerID AS PK)
Address [Address Detail, CustomerID FK]
A customer can have more than one address.
What are the advantage and disadvantage?
This is a reasonable question.
Basically, it boils down to a single question: "Do you want two identical addresses to always have the same key or not?".
In the first version, the "Address Detail" can be unique across the database. So, two room-mates could have the same AddressId. When the Smith's move out and the Jones' move in, they could have the same AddressId.
In the second version, each person would have one or more address records. However, the details for a given address could be repeated.
Which is better depends on your application. Often, the first method is preferable when you are contacting people at the address, because "de-duplication" is built into the data model
Customer Table - CustomerId, Street, City, State, Zipcode
ZipCode Table - ZipCodeId, ZipCode, CityId, StateId
However, what I am confused about it is - should I put CityId, StateId and ZipCodeId or should I put CityName, StateName and ZipCode in Customer Table? And should these be set up as referencing foreign key in city, state and zipcode tables? Should I get rid of City Table altogether and just repeat city's name in ZipCode table and Customer table?
Nominally, the customer table should only contain the street address and zip code ID (not the city or state). Note that data entry for such a normalized scheme is not necessarily straight-forward; people will expect to enter city, state, zip code (or maybe just zip code) and the onus will be on the application to map that correctly and disambiguate when necessary.
I too live in a zip code used by two cities; they even happen to be in different counties, which leads to questions about which county I live in on occasion. One of the cities has multiple other zip codes; the other only has (part of) the one zip code. There's no problem: you would have two separate ZipCodeID entries for the same ZipCode, one for each city. Note that this means that there would not be a unique index on the ZipCode column in the ZipCode table.
Where would you store the +4 of the Zip+4 scheme? Good question! That belongs with the street address.
If it is possible to have more than one city with same zip code, then a better solution that you have a City table, where you have zipcode column (just varchar or int column, no foreign key). In City table you keep foreign key from State table. At the end you should keep CityId in Customer table.
Reason for this: City and State tables are small tables, and joining them you don't make performance problem, just make index on them and everything will be fine.
Your design looks ok to me - keep full address in customer table. Just make sure that you permit to enter multiple entries into ZipCode table having the same zipcode but different cities (i.e. do not make ZipCode.ZipCode unique key).
See here:
Zip codes relate only to the mail system and have absolutely nothing
to do with political boundaries. Some cities will be covered by more
than one zip code; some zip codes will cover more than one city.
It is very frustrating when you call insurance company and after telling them zipcode they would give you really bad quote - simply because you seem to live in different city across the road, and that city has exactly the same zip code, but bad crime situation.
You can also incorporate USPS address correction into your application to standardize and keep this information normalized. See: https://ribbs.usps.gov/index.cfm?page=aec