As for the storage, in this case a database is a natural choice as it handles concurrent access out of the box, while storing in a file would require some complications on your side.
But your real concern seems to be with the data structure, not the storage. The challenge here is that different data providers provide different structures and you want them all in one structure.
If service 1 provides first name and last name as separate fields, and service 2 sees them as a single field, the question is whether you make a single field (like in service 2) and concatenate values coming from service 1, or you make multiple name fields (like in service 1) and invent a method to separate values coming from service 2 into corresponding parts.
To make this decision wisely, you have to look how your data is to be used. If you want a robot to send out emails starting with 'Dear Ms. Last Name' line, you will need to keep last name separately. If you have no such task in your planning horizon, you may wish to skip the dividing challenge and simply store all name fields in a single field.
The problem of a correct data structure for folks' names is deeper than it seems. Have a look at this nice post: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
At any rate, no-one at stackoverflow knows what your data is to be used for. It is up to you to communicate to your client that they share this knowledge with you. Then get some time to sit down and to sketch the structure that will suffice your immediate needs. Outline use cases, draw an ER diagram, put down on the paper some pseudocode to illustrate what data fields are needed by your system.
And most importantly, don't be afraid that it doesn't come out as good as you want. The needs change over time, your understanding deepens, and it is only natural to constantly adapt your database structure and your code to the new reality. It's okay. Come on, work it out.