Хороший дизайн/нормализация

Question

я была назначена задача, с которой я не знаю, как подойти к нему База данных:

Я должен построить Messaging-System, которая поддерживает несколько устройств, и это должно быть как можно более эффективным. Пользователи могут иметь до 10 устройств, которым все должны получать сообщение, когда Пользователь его получает.

У меня есть две идеи:

Table Messages: 
- ID (PK) 
- SenderID 
- ReceiverID 
- Data 

Table PendingTransmissions: 
- MessageID (FK (PK of above table)) 
- DeviceID (FK) 

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

Table Messages: 
- ID (PK) 
- SenderID 
- ReceiverID 
- Data 
- ReceivedDevice1 
- ReceivedDevice2 
- ReceivedDevice3 
- ReceivedDevice4 
- ReceivedDevice5 
- ReceivedDevice6 
- ReceivedDevice7 
- ReceivedDevice8 
- ReceivedDevice9 
- ReceivedDevice10 

Проблема здесь, очевидно, в избыточности устройств, но накладные расходы будут ниже.

Какое лучшее решение или что-то, что я пропустил полностью?

Заранее благодарен!

Answer 1

Я рекомендовал бы против 2-го подхода (по крайней мере) две причины:

• Сегодня, один пользователь может иметь 10 устройств. Если это число изменится, скажем, на 20 в будущем, это означает изменения во многих слоях вашего приложения: базы данных, классов сущностей приложений, DAO и т. Д.
• В будущем вы можете добавить функциональность для групп. Это будет громоздким, чтобы расширить этот дизайн для этого.

В 1-ом подходе, если вы обеспокоены вашей PendingTransmissions становится слишком большим по размеру, вы можете позаботиться об этом так:

• Добавьте две колонки: isDelivered и deliveredTimestamp. Затем вы можете периодически архивировать все строки, которые доставляются и старше, чем, скажем, 1 месяц.

Answer 2

Первый подход является полностью действительным, и это должен быть путь. Ремонтопригодность второго подхода - ужас, и в более позднее время, когда добавляется некоторый код, код будет не очень читабельным (мне пришлось поддерживать несколько БД уже там, где они были разработаны таким образом).