Основной вопрос проектирования базы данных

Question

Я проектирую базу данных для службы WCF, которую я создаю, и у меня есть вопрос о том, как мне ее спроектировать:
У меня есть таблица Subscriptions, таблица Events и таблица lu_Type.

**Subscription**                  **lu_EventType**
SubscriptionId int  ID PK         TypeId      int ID PK
CustomerId     int  FK            Description nvarchar
TypeId         int? FK  
Description    nvarchar

**Event**  
EventId        int  ID PK  
CustomerId     int  FK
SubscriptionId int  FK  
EventTime      datetime
TypeId         int?
Description    nvarchar  

A Customer может иметь несколько Subscription.
TypeId имеет значение NULL, поскольку Клиент может подписаться на два типа подписок. Известные события, которые будут из таблицы lu_Type, и неизвестные события, где Subscription имеет нулевой TypeId и только описание.
После регистрации Event он будет отображаться на веб-сайте на основе Customer.

1. Для известных событий, когда Event будет иметь TypeId, я должен включить Description из Event в запись? Или я должен просто оставить Description пустым? Это заняло бы больше места в БД, если бы я его включил, но это сделало бы поиск / отображение намного проще. Я не знаю достаточно о внутренней работе, чтобы знать, является ли любой из них не проблема или нет. Или, может быть, есть лучший путь в целом? (У меня может быть только одна таблица Event, она должна быть общей.) Мысли?

Answer 1

• Клиент может подписаться на многие события .
• Одно событие может быть доставлено многим клиентам .
• Событие может быть известно или неизвестно . Известное событие является событием (подтип).
• Известные события имеют все столбцы как неизвестные события и несколько более определенных столбцов.

Answer 2

Если верно следующее:

• Описание события напрямую связано с типом
• Все события одного типа должны иметь одинаковое описание
• Изменения в описании типа события должны быть отражены в существующих событиях

Вы должны не включать Description в событие, а вместо этого присоединиться к таблице типов событий, чтобы получитьit.

В противном случае описание должно быть включено в запись события, поскольку оно не имеет прямого отношения к типу события.