We are building a multitenant webservice with PHP and MongoDB. There is a need for communication between service employees and clients, communication can be established in many different ways. Some of them are: SMS, MMS, Email and, possibly, an internal chat system.
The question is, how to properly implement the database structure for it?
My boss insists, that there should be one collection -
messages, where we would store the sender, type, receiver, message body, timestamp and arguments it that way, that we would have a route which points to
users/1235/messages, where the chat history can be retrieved.
I, however, disagree on it and argument it in such a way, that every message type has its own properties and settings. For example, it would not be right to store the whole body of SMS message inside just one instance - one SMS can consist of up to 6 parts, which are delivered independently (they have their own tracking ID). This way, it is easy to track, which parts have been delivered, thus allowing to send missing parts instead of the whole message. Emails also have their own properties such as address, reply-to and other stuff.
Probably I think about constistency too much, since I've been using MySQL for a long time. But, in my opinion, storing all messages just in one collection would give a huge property diversity in the object. Storing each message system separately, however, would give flexible options, allowing to track each message's status and other details. All the messages normalized and joined into one data collection later. (Concat SMS to build the whole body, etc)
So, what kind of solution would you see here?