Блог

Я создаю веб-службу WCF и сопоставляю свою доменную модель с использованием Fluent Nhibernate, и я заметил, что объекты могут быть представлены по-разному, как и данные, стоящие за ними.

По сути, у меня есть три таблицы: одна — таблица собраний, одна — таблица мест собраний, а другая — таблица участников. В принципе, приложение будет работать таким образом, что собрание будет назначено, и участники пойдут, но они также будут голосовать за Место проведения. Таким образом, в основном на многих собраниях много участников, и многие участники имеют много голосов (при условии, что установлено ограничение, так что у них есть только один голос на собрание. Это выглядит так. Итак, чтобы представить это, у меня есть три базовые таблицы и Многие Ко многим (ко многим? Таблица)

 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
  

Мой вопрос в том, что лучше использовать эту структуру или создать две отдельные таблицы. Одна представляет участников собрания, а другая представляет голосование участника за участников собрания как таковое:

 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,
    MeetingPlaceId INT NULL,

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

Я обеспокоен, потому что я не уверен, насколько Fluent-NHibernate справится с первым решением, а второе, хотя и немного надуманное, кажется более конструктивным.

У вас должна быть ассоциативная сущность между каждым отношением «многие ко многим».

Если я правильно понимаю ваш случай:

• Собрание (информация о собрании)
• Участник (информация об участнике)
• MeetingVote (meeting_id, attendee_id, дополнительная информация)
• MeetingAttendee (meeting_id, attendee_id, дополнительная информация)

Это было бы нормализовано и правильно отображало поведение вашего приложения.

Некоторые утверждают, что если это приложение читает более 90% времени, вам следует отменить нормализацию, но если вы регулярно читаете и пишете, у вас должно быть два отдельных ассоциативных объекта.