Let's say I've 3 tables: enterprise, users, houses.
Everyone needs an address. What should I do?
Create a table address for everyone?
Create one unique table address?
Assuming that the first is "more" correct (cache, fragmentation, size, ...), how should I write it in plain SQL?
How do I create a "model" of the table address, and use it in custom tables (e.g. enterprise_address)?
* So when I change one field in the model, it gets replicated.
It appears you need every user to have an address. You have multiple ways to solve it.
Handle it in UI
Your users table will be just information about users (on address info here)
Create addresses table with addressid as primary key
Create many-to-many table/junction table called user_addresses that brings userid and addressid together
Ensure that your UI mandates address for each user
Tables
create table addresses (addressid int not null PK, line1, line2, city ...);
create table users (userid int not null PK, username, ...);
create table user_addresses (user_addressid int, userid int, addressid int, UK userid + addressid, FK to users, FK to addresses);
This allows a user to have multiple addresses. You have the flexibility of marking which one is primary.
Handle it in DB (and UI)
create table addresses (addressid int not null PK, ....);
create table users (userid int not null PK, username varchar(20), ..., addressid int not null, FK to addresses);
This allows one address per user.
and handle it also on the UI to ensure that address is supplied. Enter address into addresses first and then into users (make it an atomic process; use transactions!)
You can start with one these methods and analyze what your business needs are. Work with your DBA, if you have one, to see what their experience says about the business and previous DB designs similar to this.
Just from the three given tables I would assume that address is something you would want to put in either Houses or Users.
Depending on how much detail you want to keep track of in the Address it could be work making a separate table but there are a number of ways to go about this and the correct method depends solely on what you are trying to achieve.
Without knowing any of the required information all I can really advise is that you should aim to store the addresses as unique values. Once you have this you can assign each address to any other table you wish using a Foreign Key.
If you want to store multiple fields for the address then you will require a seperate table, if a single field will do then it could just as easily be added to the person or houses table.
One thing that would make a major difference to which way you would want to do this is the relationship between address and your other entities. For example if a user can have many addresses then you cant make it a part of the user table, and if an address can have multiple users assigned to it then it cant use a FK to represent its relationship to the users table.
One way you can do this is to make a relational table. So you make addresses and users seperate tables then have another table with just an id(pk) and 2 fks linking it to each of the other tables. This way you can have a many to many relationship if you wish.
First question: how many addresses per enterprise/user/house? If there are multiple addresses per entity, that leads you to want a separate address table, possibly with an address type.
Examples of multiple address situations:
Multiple locations
Ship-to addresses
Physical vs. PO Box
If you are going to assert that an entity can only have one address, then you probably prefer making the address part of the entity row, for simplicity. However, there can be reasons not to do that; for example, table width (number of columns in the table).
If you have multiple addresses per entity, typically you will use a foreign key. The entity should have an abstract key: some kind of ID. This will either be an integer or, in SQL Server, it could be a uniqueidentifier. The entity ID will be part of the key for the address.
Ok, I found the answer to postgresql: use INHERITS
e.g. CREATE TABLE name () INHERITS (table_model)
Thank you all for the answers.
Related
I am designing a database for a system and I came up with the following three tables
My problem is that an Address can belong to either a Person or a Company (or other things in the future) So how do I model this?
I discarded putting the address information in both tables (Person
and Company) because of it would be repeated
I thought of adding two columns (PersonId and CompanyId) to the
Address table and keep one of them null, but then I will need to add
one column for every future relation like this that appears (for
example an asset can have an address where its located at)
The last option that occur to me was to create two columns, one
called Type and other Id, so a pair of values would represent a
single record in the target table, for example: Type=Person,Id=5 and
Type=Company,Id=9 this way I can Join the right table using the type
and it will only be two columns no matter how many tables relate to
this table. But I cannot have constraints which reduce data integrity
I don't know if I am designing this properly. I think this should be a common issue (I've faced it at least three times during this small design in objects like Contact information, etc...) But I could not find many information or examples that would resemble mine.
Thanks for any guidance that you can give me
There are several basic approaches you could take, depending on how much you want to future proof your system.
In general, Has-One relationships are modeled by a foreign key on the owning entity, pointing to the primary key on the owned entity. So you would have an AddressId on both Company and Person,which would be a foreign key to Address.Id. The complexity in your case is how to handle the fact that a person can have multiple addresses. If you are 100% sure that there will only ever be a home and work address, you could put two foreign key columns on Person, but this becomes a big problem if there's a third, fourth, fifth etc. address. The other option is to create a join table, PersonAddress, with three columns a PersonId an AddressId and a AddressType, to indicate whether its a home work or whatever address.
I have following two entities, where a person address is kept in a separate table because a person can have multiple addresses.
The mailing address however is one of the multiple addresses stored in address table, which is to be referred in person table.
Can following relationship exist?
The answer to your direct question is "Yes". However, you cannot declare the model only using create table because:
Declaring the foreign key address.person_id requires that the person table already exist.
Declaring the foreign key person.mailing_address requires that the address table already exist.
Hence, to implement the model, you need to use alter table to add one or both of the constraints after both tables are created.
Is this the model you want? One feature of an address is that multiple people can have the same address. Your model does not allow that. To handle this, you would typically have three tables:
Person
Address
PersonAddress
The third table has one row for each person/address pair. It can also have other information such as:
Type ("mailing" versus other types)
Effective and end dates.
Perhaps other information.
If you want to guarantee uniqueness of the "mailing" address in such a model, many databases support filtered unique indexes, to ensure there are no duplicate mailing addresses.
I'm not sure why you have person_id as an fk on address but that doesn't look correct. There are lots of correct ways to model this and the best one for you will depend on you particular circumstances - but a couple of options are:
If you know all the types of addresses there can be then add multiple address fk fields to the person e.g. billing address, shipping address, etc. This makes querying quick and simple but is inflexible: adding a new address type in the future is relatively complex to implement
Add an intersection table with fks for person and address and an address type field. This has a slight overhead when it comes to querying but has the advantage if being very flexible: adding a new address type is trivial
First of all, I do realize that there are plenty of questions regarding this problem and there is a good chance that I already know one of the answers, but after I've tried a couple of them, none of them worked for me.
In my application I am handling communication between user and customer. Both users and customers can have multiple e-mail addresses. Also, both users and customers can be assigned to multiple conversations at the same time. After user or customer sends an e-mail message, system receives information about that and creates a ConversationMessage with basic info about the message and EmailMessage with specific data (subject, FROM, TO etc.).
Right now, fields FROM and TO are just varchar fields with e-mail addresses. I would like to change it so that FROM and TO fields are foreign keys. I was planning to create an EmailAddresses table that would store basic info about the address and UserEmailAddresses and ContactPersonEmailAddresses tables with specific info about address (like host, port etc.), but I realized that EmailAddresses table would contain just an Id. Is it a good approach? Am I missing something?
Are there any better solutions to this kind of problem?
Thank you for any help!
There are numerable issues with the design but let's limit the discussion to the email addresses. You store the addresses in two tables. This, unsurprisingly, is causing problems.
An email address is an entity. Store them in a table. Anywhere a single address is needed, place a FK to the one address table there. Where multiple addresses is or may be needed, place an intersection table there.
create table EmailAddresses(
ID int auto_generating primary key,
Addr varchar not null unique,
Active bool
);
Are such fields as Login, Port, etc. really attributes of an email address? Maybe you could clarify those if you would.
Then the tables UserEmailAddresses and ContactEmailAddresses would be intersection tables and look something like this:
create table [User|Contact]EmailAddresses(
UserID int not null references [Users|Contacts]( ID )],
AddrID int not null references EmailAddresses( ID )
);
As an email message can only have one "From" value, that would be in the EmailMessages row as it is now except it can now be a FK to the one address table. A message may have one or many "To" values so that would be implemented also as an intersection table:
create table EmailTo(
EmailID int not null references EmailMessages( ID )],
ToID int not null references EmailAddresses( ID ),
ToType enum( To, CC, BCC )
);
There are probably other requirements that would require some constraints on any or all of the tables above but those depend on your usage. For example, even though email applications allow the same address to exist more than once in a From list, you may want to catch and restrict such occurrences. This would be implemented by a unique constraint on (EmailID, ToID)
Possible extensions would be the addition of email lists which themselves contain a group of addresses. That would require the EmailAddresses table to split but because all addresses are now located in one table, such a redesign would certainly be easier that having them located in two tables.
I am creating a data warehouse from a store database and I have a question regarding the design of my dimensions and facts.
In the store database a table exists for Person, Person_Address and Person_Address_Type. These are linked by another tabled name Entity_Address_ID which links the three tables by their primary keys to give details on what a person's address is and what type of address it is.
My question is, should I create a dimension for all three tables, and a fact-less fact table to link them together or should I de-normalise my dimensions and add to each dimension a foreign key for the address and address type they are linked too?
Here is a very quick UML of what the current database looks like to provide clarification
You should create a Person dimension with a set of address attributes (mailing address, billing address, etc), i.e. denormalize all this data and load it into a single table.
Suppose i have a table with 3 fields
Person_id, Name and address. Now the problem is that a person can have multiple addresses. and the principle of atomic values says that data should be atomic.
So then how am i suppose to store multiple addresses for a single person ?
You're supposed to create an ADDRESS table that has a foreign key linking it to a PERSON record, i.e. PERSON_ID. This is the "relational" component of a relational database, and it's why it's more flexible than a flat file (which is like a single table).
Put adresses in a second table, give each adress a "Person ID", so that mutiple rows in the adress-table can referr to on person.
I would suggest adding a address type to the address table to identify which type of address it is (Home, Vacation, Office), etc. Something like: AddType that refers to a list table where more types could be added down the road.