Better to use two many to many tables or one table with three Foreign Key References

I'm Creating a WCF Web Service and mapping my domain model using Fluent Nhibernate and I have noticed that the objects can be represented in different ways and so can the data behind it.

Basically I have three tables, one is a Meetings table, one is a MeetingPlaces table, and the other is an Attendee table. Basically the application will work such that a Meeting is set up, and Attendees will go, but they will also vote for a Location. So Basically Many Meetings have Many Attendees, and Many Attendees have Many Votes (granted a constraint is put on such that they only have one vote per meeting. It looks as such. So to represent this I have the three base tables and a Many To Many (to many? Table)

CREATE TABLE Meetings (
    Id INT NOT NULL PRIMARY KEY IDENTITY,
    Name NOT NULL,
    StartTime DATETIME NOT NULL,
    EndTime DATETIME NULL,
)

CREATE TABLE Attendees (
    Id INT NOT NULL PRIMARY KEY IDENTITY,
    Name NOT NULL
)

CREATE TABLE MeetingPlaces (
    Id INT NOT NULL PRIMARY KEY IDENTITY,
    Name NOT NULL,
    Address NULL
)

CREATE TABLE MeetingAttendees (
    Id INT NOT NULL PRIMARY KEY IDENTITY, 
    MeetingId INT NOT NULL, 
    AttendeeId INT NOT NULL, 
    MeetingPlaceId INT NULL, --in case they have no preference

    CONSTRAINT  FK_MeetingAttendees_To_Events FOREIGN KEY (MeetingId) REFERENCES Meetings(Id),
    CONSTRAINT  FK_MeetingAttendees_To_Attendees FOREIGN KEY (AttendeeId) REFERENCES Attendees(Id),
    CONSTRAINT  FK_MeetingAttendees_To_MeetingPlaces FOREIGN KEY (MeetingPlaceId) REFERENCES MeetingPlaces(Id)
)
GO

CREATE UNIQUE INDEX U_IDX_Meeting_Attendees ON MeetingAttendees(MeetingId, AttendeeId)
GO

My question is, is it better to use this structure, or create two separate tables. One representing The Attendees to a meeting, and the other representing the attendee's vote to meeting attendees as such:

CREATE TABLE MeetingAttendees
    Id INT NOT NULL PRIMARY KEY IDENTITY, 
    MeetingId INT NOT NULL, 
    AttendeeId INT NOT NULL, 

    CONSTRAINT  FK_MeetingAttendees_To_Events FOREIGN KEY (MeetingId) REFERENCES Meetings(Id),
    CONSTRAINT  FK_MeetingAttendees_To_Attendees FOREIGN KEY (AttendeeId) REFERENCES Attendees(Id),
)
GO

CREATE UNIQUE INDEX U_IDX_Meeting_Attendees ON MeetingAttendees(MeetingId, AttendeeId)

CREATE TABLE AttendeeVote(
    Id INT NOT NULL PRIMARY KEY IDENTITY,
    MeetingAttendeeId INT NOT NULL,
    Meeting开发者_开发知识库PlaceId INT NULL,

    CONSTRAINT FK_AttendeeVote_To_MeetingAttendees FOREIGN KEY (MeetingAttendeeId) REFERENCES MeetingAttendees(Id),
    CONSTRAINT FK_AttendeeVote_To_MeetingPlaces FOREIGN KEY (MeetingPlaceId) REFERENCE MeetingPlaces(Id)
)

I'm concerned because I'm not sure how Fluent-NHibernate will handle the first solution, and the second, while a bit contrived seems more structurally sound.

---

You should have an associative entity between each many-to-many relationship.

If I understand your case correctly:

• Meeting (meeting info)
• Attendee (attendee info)
• MeetingVote (meeting_id, attendee_id, more info)
• MeetingAttendee (meeting_id, attendee_id, more info)

This would be normalized and properly represent the behavior of your application.

Some would argue that if this application is reading 90+% of the time than you should de-normalize, but if you are reading and writing regularly you should have two separate associative entities.