Firestore and a docs

[Alex Grissom]

Hello!

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. 

[Tracy Hall]

Always design your data structures the way you need to *use* the data.  The delta cost for small sub-documents is comparatively small, and it's how firebase was designed to be used.

[Alex Grissom]

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?

Since firebase requires a field ID for each data set in a doc and it does not seam to create that field ID like it does the doc ID when created then I would use the input from the user to as the field ID. This would solve the problem with no auto dynamic field ID creation. Thoughts?

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/6pQ57yx46DA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebase-talk/4c32ff1f-8536-4a75-bd1e-e6de4d409781n%40googlegroups.com.

--

Alex Grissom

BetterTechnologySolutions LLC

Lead Project Manager /  Programmer

936.229.4774

https://www.BetterTechSol.com/

Schedule an Appointment Here

https://live.vcita.com/site/bettertechbooking/action/jiokhqevnrgrxdct

Managed I.T. Services, security and Custom Web Development

We offer managed security, digital services and build custom tools for business

[Tracy Hall]

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

[Alex Grissom]

Well put. Thank you for the help! 

-Sent from mobile-
Best wishes,
Alex Grissom
BetterTech

CONTACT
bettertechsol.com/nice-meeting-you

To view this discussion visit https://groups.google.com/d/msgid/firebase-talk/981e76a2-0b93-477c-a6af-f193422bdfc1n%40googlegroups.com.

[Wilfred Macaulay]

Very well said, if I may add.

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.

Cheers Tracy!