Лучше использовать две таблицы «многие ко многим» или одну таблицу с тремя ссылками на внешние ключи - PullRequest
Новая
       2

Лучше использовать две таблицы «многие ко многим» или одну таблицу с тремя ссылками на внешние ключи

0 голосов
/ 09 октября 2011

Я создаю веб-службу 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 справится с первым решением, а второе, в то время как немного изобретательно, выглядит более конструктивно.

1 Ответ

0 голосов
/ 09 октября 2011

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

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

  • Встреча (информация о встрече)
  • Attendee (информация о посетителе)
  • MeetingVote (meeting_id, Participdee_id, дополнительная информация)
  • MeetingAttendee (meeting_id, attendee_id, Дополнительная информация)

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

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

...