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.
Related
Say for example, I have an ADDRESS table, that will store similar attributes of other entities like address, city, zip, country, etc. The entities are USER, COMPANY, BANK, BRANCH, etc. I would like to use this one table ADDRESS to store the addresses of the other entities rather than creating other tables for each entity to store the ADDRESS like so, USER_ADDRESS, COMPANY_ADDRESS, BANK_ADDRESS, BRANCH_ADDRESS.
Is this possible? Am i breaking any laws or conventions? What are the consequences, if any?
Each entity (USER, COMPANY, etc.) should contain a reference to an entry in the ADDRESS table.
There are a few issues:
If 2 users have the same address, they should reference the same address id.
You will need to normalise addresses so that you're not duplicating information (e.g. if you know the city, then you automatically know the zip and country).
Of course, you may not want a well-normalised database. Saving the entire address as a string will improve read performance by reducing the number of join operations.
A lot of things depend on the exact use of the database.
It is fine to use a single ADDRESS table for that purpose and have an ADDRESS_ID in each of the other entities. Depends on the use case and the way you prefer to implement it. I most probably wouldn't do it. I also wouldn't do the other solution you're suggesting (an address table per entity).
So, let's say you want to implement a function to search for all the addresses, where it doesn't matter what type of entity is connected to it. You will have to search the ADDRESS table. If you get results, then you have to search the other four tables to see which record is connected to that address.
You could add a field ENTITY_TYPE in the ADDRESS table where you specify which type of entity it is connected to, so you don't have to search the four tables, but I don't recommend this since you can have consistency errors (USER 17 points to ADDRESS 14, but ADDRESS 14 has ENTITY_TYPE = BANK).
Now, with your other solution (having four separate tables to store the addresses of the four different entities) you're just going to have to search those four tables and then search the corresponding entity table to get the entity you're looking for.
My solution in most cases is adding the address fields to the entities tables themselves. Having ADDRESS, ZIP_CODE and COUNTRY_CODE (always use proper country codes, not country names https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes) will make it simple. When you present a list of items (users, banks, companies, offices, whatever), it's really common to show the name and the address at the same time in a table. Having no JOINS makes it faster and easier to process. If you want to update an address, it's on the table itself. No lookups!
Of course, like most things in programming, it depends on what your needs are.
Also, please, don't try to split the ADDRESS in more fields. I've seen ADDRESS_TYPE (street, road, avenue, square, ...), STREET_NAME, STREET_NUMBER, BLOCK_NUMBER, BLOCK_FLOOR, BLOCK_LETTER. I'm pretty sure you're never going to need something like SELECT * FROM USER WHERE STREET_NUMBER = 74.
I have been asked to add a new address book table to our database (SQL Server 2012).
To simplify the related part of the database, there are three tables each linked to each other in a one to many fashion: Company (has many) Products (has many) Projects and the idea is that one or many addresses will be able to exist at any one of these levels. The thinking is that in the front-end system, a user will be able to view and select specific addresses for the project they specify and more generic addresses relating to its parent product and company.
The issue now if how best to model this in the database.
I have thought of two possible ideas so far so wonder if anyone has had a similar type of relationship to model themselves and how they implemented it?
Idea one:
The new address table will additionally contain three fields: companyID, productID and projectID. These fields will be related to the relevant tables and be nullable to represent company and product level addresses. e.g. companyID 2, productID 1, projectID NULL is a product level address.
My issue with this is that I am storing the relationship information in the table so if a project is ever changed to be related to a different product, the data in this table will be incorrect. I could potentially NULL all but the level I am interested in but this will make getting parent addresses a little harder to get
Idea two:
On the address table have a typeID and a genericID. genericID could contain the IDs from the Company, Product and Project tables with the typeID determining which table it came from. I am a little stuck how to set up the necessary constraints to do this though and wonder if this is going to get tricky to deal with in the future
Many thanks,
I will suggest using Idea one and preventing Idea two.
Second Idea is called Polymorphic Association anti pattern
Objective: Reference Multiple Parents
Resulting side effect: Using dual-purpose foreign key will violating first normal form (atomic issue), loosing referential integrity
Solution: Simplify the Relationship
The simplification of the relationship could be obtained in two ways:
Having multiple null-able forging keys (idea number 1): That will be
simple and applicable if the tables(product, project,...) that using
the relation are limited. (think about when they grow up to more)
Another more generic solution will be using inheritance. Defining a
new entity as the base table for (product, project,...) to satisfy
Addressable. May naming it organization-unit be more rational. Primary key of this organization_unit table will be the primary key of (product, project,...). Other collections like Address, Image, Contract ... tables will have a relation to this base table.
It sounds like you could use Junction tables http://en.wikipedia.org/wiki/Junction_table.
They will give you the flexibility you need to maintain your foreign key restraints, as well as share addresses between levels or entities if that is desired.
One for Company_Address, Product_Address, and Project_Address
Consider the following Relational Schema:
I am trying to fully Normalize (In Third Normal Form) and determine the functional dependencies. However, with endless research, I cannot get around on how to:
Fully Normalize the Relational Schema
Determine the Functional Dependencies
How would I go about this?
An employee can be a customer, and may become a manager one day. Use the Party Model. "Employee" or "Customer" should be a role played by a Party. A Party hasMany Roles
People can have no address, one address, or multiple addresses. People can share the same address. Use an Address table, and a PersonAddress junction table. Same with phone numbers.
You'll probably want to have individual customers and organization customers (companies or shared accounts). Use the Party Model.
Why does Branch not use a BranchId when all the other tables use id columns?
Are you sure a Customer is assigned to an Employee? What if the employee is on vacation?
Why "city" and "town" in Branch?
We are designing a SQL Server database with link tables for many-to-many relations.
The question is are there any best practices for naming these kinds of tables for use with the entity framework?
Let's say there's a table
Customer
and
Address
Then there is a link table between them, what do we call it?
CustomerAddress ? Or something else?
Thnx
For example, users - UsersInRoles - Roles. If CustomerAddress does not contains anything except CustomerID and AddressID, EF'll generate only two entities Customer (with Addresses property) and Address (with Customers) and there is no any matter how you call this intermediate table
I am trying to create a database to hold my address book but I've ran into a slight problem.
My database is supposed to hold individual contacts along with company contacts. That is an entry can be either for an individual or a company. As you know both individuals and companies have addresses and I want a One-To-Many relationship between individuals and addresses as well as companies and address.
So an individual can have many addresses
and a company can has many addresses
the problem is when trying to design the schema I am not sure what the best approach here is. Should I put two foreign keys in the address table, one for individual_Id and one for company_Id or should I create a linking table for each individual to address and company to address relationships.
The foreign keys do sound easy but don't know if that's the right approach, and linking seem like the right approach but don't know if this is overkill as they are mostly used for Many-To-Many relationships.
Thoughts?
There are various approaches to this...The approach we took was to have a "Names" table, the equivalent of your contacts table; an addresses table, and a phone numbers table.
The addresses and phone numbers tables each had a foreign key to the names table. The names table had a "type" field in it so that we could tell if the name was that of an individual, company, sole proprietor, etc.
The phone numbers table had a type field in it also, so we could tell whether the phone number was Work, Home, Cell, etc. In addition, we allowed the user to store a copy of one of the phone numbers in the Name table to serve as a Primary phone number.