I have two entities customers and stores and they both need adresses should i do different adresses tables for each entity or use one for both with 2 different foreign keys but the the 2nd case i will probably have a lot of null values in my table since only one of both will be filled.
If the fields of the address table are similar for each entity I would use one address table with foreign keys.
If there are lots of specifics fields for customers and stores in your address then i would use 1 table for each...
Related
Do I really need an extra identity field say called id on a bridge table? For primary tables I set an id and have it start incrementing from 0. But not sure about bridge tables.
Example:
user
user_id (identity)
name
user_communities
id (identity) - do I even need this??
user_id
community_id
communities
community_id (identity)
name
No, you don't need an additional generated primary key on a bridge table - at least not if (user_id, community_id) is the primary key.
You would only need it in case you would allow a user to participate in the same community multiple times, e.g. with different roles.
Your relationship links two entities, thus you have the ids of the two entities in it. In that case the id in your bridge table is unnecessary.
But, although rarer, you could also have higher order relationships which connect two relationships or a relationship with other entities. Say, for example, you want to qualify a relationship with a set of properties (the strength of the relationship, its participants, etc), you could have a relationship properties table that links to the relationship (thus you would need its id) to a set of name-values pairs. You could even have a bridge table between two different bridge tables to connect them and assign certain properties to the connection (which relationship has priority over the other, e.g.)
Is there a condition in which two database tables can have more than one relationship between them? I saw a data model diagram which has something like that.
Yes, when a primary key from one table is used as a foreign key in another for several times. For instance, you may have a table "people" and a table "books" where books table will have fields writer_id, editor_id (among others) all referencing the primary key from people table.
I'm likely overthinking a problem here and may well get downvoted but I'm prepared to take the hit. I'm building my first schema in a data warehouse.
2 tables: events and contacts:
events(id(pk), cid, other, fields, here)
contacts(id (pk), cid(fk), other, fields, here)
Someone visits our website and registers. A line item is generated in events column "id" and a "cid" for contacts is generated. A new record is added to contacts.
I have two questions:
Can I make the primary key of contacts cid? Thus the primary key is also a foreign key?
I'm using MySQL Workbench to create the schema. When I create the contacts table I am able to set the foreign key of cid and the cardinality as either 1-1 or 1-many. From the point of view of contacts table, is the relationship 1-1 or to many? There will only ever be 1 cid record in contacts but if that user does multiple things (like receive an email from us etc) they will appear multiple times in events table. So, logically 1-many. But when creating this in Workbench the relation line appears as though it's a 1-many relation with the many part being at contacts, not the other way around as desired. It should be the other way around?
What is the relationship between events.cid and contacts.cid?
If a user's registration results in a single contact_ record while each user visit to the web site (each Session started) results in an event_ record belonging to that user’s contact_ record, then you have a One-To-Many relationship.
`contact_` = parent table (the One)
`event_` = child table (the Many)
Notice how I boiled down that relationship into a single sentence. That should be your goal when doing analysis work to determine table structure.
Relationships are almost always defined as a link from a primary key on parent table to a foreign key on a child table.
How you define the primary key is up to you. First decide whether you want a natural key or a surrogate key. In my experience a natural key never works out as the values always eventually change.
If using a surrogate key, decide what type. The usual choices are an integer tied to an automatically incrementing sequence generator, or a UUID. If ever federating data with other databases or systems then UUID is the way to go. If using an integer, decide on size, with 32-bit integers handling a total of 2-4 billion records. A 64-bit integer can track 18 quintillion records.
The foreign key in child table is simply a copy of its assigned parent’s primary key value. So the foreign key must have same data type as that parent primary key.
If a particular parent record owns multiple records in the child table, each of those child records will carry a copy of that parent’s primary key. So if the user Susan has five events, her primary key value appears once in the contact_ table and that same value appears five times in the event_ table stored in the foreign key column.
If cid uniquely identifies each contact_ record amongst all the other contact_ records, then you have a primary key. No need to define another.
I'm trying to workout the best database design for the following :
1) I have two (or more) tables in the database. "Sports", "Teams", "Leagues", etc..
2) Each of these tables can have a one to many relationship with another table in this case "Feeds"
The idea being that various database entities can each have a list of associated "Feeds"
It seems wrong to me to have multiple foreign key columns on the "Feeds" table, one for each of the tables (Sport, League, etc..), so my question is how best to model this?
It's worth mentioning that each feed can only belong to one of the other tables. A feed can't be associated with a "Sport" and a "League"
I've considered the following :
1) Add an additional column to each of the "Sport" "League" etc.. tables with a GUID.
2) Add another column to the "Feeds" table also with a GUID and populate this with the GUID from my other table, then query on this.
This would allow me to have multiple tables referencing the same column of the "Feeds" table but is this any better than having multiple nullable foreign keys, one for each table?
It is not a bad idea to have a foreign key pointing to Feeds in several tables. Foreign keys can be used to handle the 1:n relation (one-to-many).
It seems wrong to me to have multiple foreign key columns on the
"Feeds" table, one for each of the tables (Sport, League, etc..), so
my question is how best to model this?
Why do you think it is not a good practice, what would be the downside of this design?
I would like to map all many-to-may relations through a single table in my database.
Meaning that I have numerous tables (entities) that have various many-to-many relations. Instead of having a separate mapping table for every relation I would like to use one "master mapping" table having to columns: End1Id & End2Id.
Don't ask why ;) It's required by my customer...
How would I set this up in the model designer, or do I have to edit the edmx xml directly....or is it just not possible?
Thanx for your help!
In such a scenario you can't have explicit foreign keys, because a table like this normally has at least three rows:
PK of table 1
PK of table 2
Type of mapping, which specifies the exact tables to use.
Because of that, you can just create a table in EF, but it will also have no connections to other tables and you will have to do the joins manually.
You would need to set this Master Mappings table manually. The designer doesn't do it for you automatically.
However - if denormalized entities are what you are looking for, better have those denormalized in DB level rather than in EF/code level.