What does architecture says and practically am I correct?
I'd say you are wrong in a common and completely understandable way. The literature on this point has a lot more noise then signal.
PATCH and PUT are method tokens used to indicate the semantics of the HTTP request. PUT means "make your representation of this resource look like the body of this request". PATCH means "apply the changes in the body of this request to your representation of this resource".
In other words, the semantics of the messages are those of remote authoring -- these are precisely the methods we would use if we wanted to edit an HTML document through the web interface itself.
So if you are writing an HTTP aware document editor, the choice between PUT and PATCH largely concerns two tradeoffs - the size of the HTTP request body, and using general purpose idempotent message semantics. As a general rule, you would choose PUT unless both of the following are true: the patch document representation of the changes is significantly smaller than the document representation, and that you don't want general purpose HTTP components automatically resend requests when responses are lost.
If you are implementing the server - ideally you'd implement both methods, so that the remote client can choose the request message appropriate for its circumstances.
"Number of fields" doesn't really enter into it, because PUT/PATCH is of the transfer-of-messages-over-a-network domain (see Webber, 2011). The employee table is an implementation detail, hidden behind the HTTP interface.
In other words, what we're really trying to do here is make changing fields in the employee table look exactly like copying a document into a document store.