Actuallyn there are many situations/use cases, and it is why I greatly appreciate Adobe Campaign, which is both powerful and flexible to manage all these cases...
For example, in some cases I use the triple key (first name, last name, email) to reconciliate (insert/update) records, so it manages quite well registration forms and updating forms that retrieves the right record, in case of an household, where the family shares the same email but the different people give their own last name/first name ; in that case, the 1-n relationship tables insert/update are done with the iRecipientId returned.
In other cases, perhaps the majority I guess, using email as key is enough. Just take care that unicity email is not guaranteed by Adobe Campaign (no unique index on email in factory schema nms:recipient).
Depending on your use case, sending a delivery to an ID means only one message/email, while sending to email can lead to several messages, even if you can let the engine selecting one record among several thanks to the Duplicate addresses exclusion rule of the delivery. If email is unique for your dataset, there is no problem to submit your delivery directly as well.
Regarding the delivery, you can either use the standard Delivery activity in the workflow with the targetData information (best and easiest way), or use JSAPI submitNotification function (and a continuous delivery most probably) if it is done by your own loop management, either in a workflow or a webApp, such as this code below:
Just a little odd because this example was shared in Adobe's online documentation.
I take your point on email being used as a key, I would rarely do so - more often than not we tend to use a unique customer id because as you say, in many situations email isn't going to be completely unique amongst a large data set.
Regarding your comment about creating the master data before creating relational data, this makes sense - I just wanted to know the best approach.
e.g. is it possible to create the master recipeint data and relational schema data (e.g. purchases data) in the same request.
do we have to split them out into seperate sequential requests.
I have a scenario that i would like to create the example request(s) for:
* Creating (or updating) recipient record(s). With "Customer ID", Email Address etc.
* Adding data to a purchases schema with "Customer ID", Purchase name, Purchase price etc (the schema is linked with a 1-n relationship with a join on "Customer ID" in recipient schema and purchases schema)
* Triggering a delivery template to these recipient records (looping in the purchase table data). I'm comfortable on the settings needed to make this possible (just curious on the best approach of ensuring the data is all added correctly before the email is attempted to be sent).
In your case, you try to add in same time the List service and the recipient in same operation. I think you must split the operation, or perhaps it works only for update the recipient, not insert at the same time. Though I am not sure. But I always create the master data before adding/modifying the linked data.