I have two tables:
- Attendees
- Events
Normally, I would create a mapping table 'EventAttendeeMap' to link these tables into a many to many relationship.
Is this the best way of doing so?
Should I store the list of AttendeeIds in an xml column instead on the Events table?
I am using .NET 3.5/4 with Linq as the DAL (although I think this is irrelevant to the design question being asked, possibly).
Interested to see what people's opinions are.
Thanks.
Dave
A mapping table is definitely the best way to do it - the Entity Framework will convert the mapping table into a collection of entities on both sides and the table itself will essentially disappear.
In short yes - create a mapping table to hold the event id and the attendee id.
There is a good question here that might be of interest to you.
Related
Say I have two query types, they both have a key column (as it happens, I'm querying an SCCM database by its views) called ResourceID.
The way I read the documentation this may not be possible since a Query Type cannot be the principal end of a relationship.
Can anyone confirm/deny this?
I don't think specifics are required for this question, but if you feel they are I can add some.
Yes! You cannot create one-to-one between two query types because query type cannot be principal end of a relationship whereas in between one-to-one principal end of a relationship is a must.
I have just started a course on database design and have been given a homework where one of the tasks is to list all the entity types of a fictional hospital according to this pdf: http://docdro.id/mbzdtUg.
I am struggling to figure out what should be an entity type and what should not. I will give you a basic example:
"Staff" is obviously an entity type but each of the staff have to have details regarding their qualifications and work experience. Since a staff member can have multiple qualifications and multiple work experiences these cannot be attributes... right? So should "Staff Qualification" and "Staff Work experience" be an entity type?
According to entity definitions I have read entities should be independent and represent objects that actually exist. What does it mean for an entity to be independent exactly? The "Staff Qualification" and "Staff Work experience" entity types would not exist if the entity type "Staff" didn't exist. Therefore they aren't independent (???) nor do they represent something that exists (physical object). Then what are they if not entity types? Should for example "Appointment" be an entity type? I am really confused... any help is appreciated.
Thanks!
EDIT: Should mention that this should be following a Entity-Relationship model (ER)
EDIT 2: Example 2: A patient can be either a outpatient or a inpatient. Should I make these into 2 entity type or only 1 (Patient)?
Looks like you're on the right track and your understanding is correct. If you foresee that Staff table can have multiple qualifications or work experiences - then qualification and work experience itself should be separated into a different entity table, so should the Appointment.
This is also where the normalization comes into place - because you could have two different staff members have the same work experience (or qualification) - then technically you don't want to just simply have a child table for Staff as that would result in a lot of data duplication. Usually, using normalization principles you would instead create a separate entity table WorkExperience where you would have all your different WorkExperiences. There would be no relationship between Staff and WorkExperiences tables. But you would also create StaffWorkExperiences table (joining table/buffer table), which would be a child of Staff (1:M) , but would also have a constraint to WorkExperiences table (M:1). So essentially you would end up with Staff table linking to StaffWorkExperiences table and the StaffWorkExperiences table in turn linking to WorkExperiences table.
Lastly, if you also have a patient table and the patient can be either outpatient or an inpatient - then that is more like a property and there is no need to have an extra table - so you would have only a patient table and then another column (PatientType or something like that) to describe this particular property.
EDIT
I have added an example schema of how this would look like with a joining table.
I'm making a website for a client but I stumbled upon a problem and I need some advice on it.
For each project, they want to have the possibility to set a variable amount of images and (sometimes) some corresponding text.
I was thinking about storing all of the information in one field, instead of making field_1 to field_99 just in case they need 99 fields.
// database column
'../fotos/foto1.png',
'hier komt tekst',
'../fotos/foto2.png',
'', (empty text)
'../fotos/foto3.png'
This solution has some disadvantadges, there must be better manners out there to achieve this.
What's the preferred way to do this?
Create another table (e.g. FOTO_CODES) with all possibly values of foto and generate id for them.
Create another child table that will have the master table record id and ID from FOTO_CODES table and FOTO data (Image).
It's called normalization.
The solution you described violates the principle of atomicity and therefore the 1NF. You'd have trouble maintaining and querying data in this format.
This is a classic 1-to-many relationship, that can be modeled in two ways:
1) Identifying relationship:
2) Non-identifying relationship:
Both have pros and cons, StackOverflow already has plenty of discussions on this topic.
I have seen people often use a separate table to store relations between tables.
Example,
Table Company_companys has two columns a nodeid which is a company id and a linkid which is a companyid of a different company.
Why do people do this when the same thing could be accomplished with an extra column in the Company table? Is is for performance reasons? or is there some other reason?
EDIT: Thanks everyone for the answers and examples, I understand now that in order to achieve First Normal Form when a many to many relationship is necessary, a separate table is needed to store the multiple links. When thinking about the above question I had pretty much forgotten the concept of many to many relationships so I was thinking about it from a one to many relationship point of view :)
It's probably because it's representing a MANY TO MANY relationship. With the approach you are mentioning, you only have a ONE TO MANY relationship.
So, in your example, if your tables semantic mean to represent any company probably relating to many other companies, you need a separate table for that.
The additional "link" table is required if you have Many to many relationship
It is to resolve an issue with many-to-many (..) relationships. Using a third table with foreign keys creates 2 one-to-many relationships as a many-to-many relationship is usually bad database design.
I have to add functionality to an existing application and I've run into a data situation that I'm not sure how to model. I am being restricted to the creation of new tables and code. If I need to alter the existing structure I think my client may reject the proposal.. although if its the only way to get it right this is what I will have to do.
I have an Item table that can me link to any number of tables, and these tables may increase over time. The Item can only me linked to one other table, but the record in the other table may have many items linked to it.
Examples of the tables/entities being linked to are Person, Vehicle, Building, Office. These are all separate tables.
Example of Items are Pen, Stapler, Cushion, Tyre, A4 Paper, Plastic Bag, Poster, Decoration"
For instance a Poster may be allocated to a Person or Office or Building. In the future if they add a Conference Room table it may also be added to that.
My intital thoughts are:
Item
{
ID,
Name
}
LinkedItem
{
ItemID,
LinkedToTableName,
LinkedToID
}
The LinkedToTableName field will then allow me to identify the correct table to link to in my code.
I'm not overly happy with this solution, but I can't quite think of anything else. Please help! :)
Thanks!
It is not a good practice to store table names as column values. This is a bad hack.
There are two standard ways of doing what you are trying to do. The first is called single-table inheritance. This is easily understood by ORM tools but trades off some normalization. The idea is, that all of these entities - Person, Vehicle, whatever - are stored in the same table, often with several unused columns per entry, along with a discriminator field that identifies what type the entity is.
The discriminator field is usually an integer type, that is mapped to some enumeration in your code. It may also be a foreign key to some lookup table in your database, identifying which numbers correspond to which types (not table names, just descriptions).
The other way to do this is multiple-table inheritance, which is better for your database but not as easy to map in code. You do this by having a base table which defines some common properties of all the objects - perhaps just an ID and a name - and all of your "specific" tables (Person etc.) use the base ID as a unique foreign key (usually also the primary key).
In the first case, the exclusivity is implicit, since all entities are in one table. In the second case, the relationship is between the Item and the base entity ID, which also guarantees uniqueness.
Note that with multiple-table inheritance, you have a different problem - you can't guarantee that a base ID is used by exactly one inheritance table. It could be used by several, or not used at all. That is why multiple-table inheritance schemes usually also have a discriminator column, to identify which table is "expected." Again, this discriminator doesn't hold a table name, it holds a lookup value which the consumer may (or may not) use to determine which other table to join to.
Multiple-table inheritance is a closer match to your current schema, so I would recommend going with that unless you need to use this with Linq to SQL or a similar ORM.
See here for a good detailed tutorial: Implementing Table Inheritance in SQL Server.
Find something common to Person, Vehicle, Building, Office. For the lack of a better term I have used Entity. Then implement super-type/sub-type relationship between the Entity and its sub-types. Note that the EntityID is a PK and a FK in all sub-type tables. Now, you can link the Item table to the Entity (owner).
In this model, one item can belong to only one Entity; one Entity can have (own) many items.
your link table is ok.
the trouble you will have is that you will need to generate dynamic sql at runtime. parameterized sql does not typically allow the objects inthe FROM list to be parameters.
i fyou want to avoid this, you may be able to denormalize a little - say by creating a table to hold the id (assuming the ids are unique across the other tables) and the type_id representing which table is the source, and a generated description - e.g. the name value from the inital record.
you would trigger the creation of this denormalized list when the base info is modified, and you could use that for generalized queries - and then resort to your dynamic queries when needed at runtime.