Firestore and a docs

I would like to store an array of employee positions into a single doc, however, I need to be able to add and remove values with variable field names as they are dependent on the users current needs. Essentially, this will be like treating the doc as a collection. Reason being, it seams silly to store multiple docs with a single field in this use case. However, if that is what is needed that is what Ill have to do. 

What do you think? This is in NextJs and will be server side. 

Thank you Tracy! Considering cost was one reason I was thinking about doing it this way. I understand firebase charges for each write or read by doc. So If I add all the info into a single doc then it would lower cost by calling that one doc instead of several. Especially if the app was to scale. Thoughts?

You are confusing different objects: a "document" is a set of key/value pairs - the "key" being what you are calling a "field Id". What you are apparently calling the "doc Id" is NOT IN the document itself - it is a unique identifier of/for the document.

Both the "documentId" and the keys/"fieldId" are completely arbitrary; as a convenience, Firebase can generate a uuid to use as a "documentId" at the time of creation.  This is NOT actually best practice, except possibly at the highest level.  If you have an existing, unique, value for a sub-document you intend to create, use it - it can be useful in general structure.  However, note that (except at the highest/root level), you cannot search/query for documents by this Id - Firebase's index is ACTUALLY the fully-qualified hierarchical path to the document (see this StackOverflow document I wrote years ago, which still applies: https://stackoverflow.com/questions/56149601/firestore-collection-group-query-on-documentid/58104104#58104104 )

This is not at all the time to be overly concerned with potential costs - the development level costs of Firebase/Firestore are virtually zero, AND you are extremely likely to *completely* redesign you system at least a few times before deployment - early optimization can be the death of a project.

Tracy Hall

Couldn't agree more on ...early optimization can be the death of a project. I just need to remind myself that from time to time.

I say the perused the SO document you referenced; couldn't stop grinning.