There's nothing wrong with this model, so far as your question goes. Lots of systems store an encrypted key alongside the ciphertext (examples include most disk encryption tools and many file or email encryption tools, such as PGP).
Whether it's a good idea to do things this way depends on what you're trying to achieve.
- If you need to make it possible to rotate the master key without decrypting and re-encrypting everything, this approach makes sense.
- If you're just trying to ensure that each message is encrypted independently, so that two messages of the same content will have different ciphertexts, that's what Initialization Vectors (IVs) / Nonces are for, and you don't need separate keys at all (the IV/nonce is usually stored, in plain text, next to the ciphertext; it's not a secret at all you just need to not ever reuse it with a given key).
- If you're trying to store data on behalf of another party (for example, a message you encrypted for the recipient), your scheme still works but you should be encrypting the per-message keys with the recipient's public key, rather than with a shared symmetric key (this is how GPG and S/MIME typically work).
Bear in mind that you'll still need integrity protection on that data. Encryption, by itself, does not prevent tampering with the data, regardless of how well the key is protected. Use a message authentication code of some sort (HMAC, a keyed hash construction, is standard) or use authenticated encryption (Galois/Counter Mode, or GCM, is standard) and store the integrity/authentication data alongside the ciphertext.