Each and any app I develop has plenty of input forms which in turn have
plenty of input fields made out of combos, listboxes, radio/checkboxes ect.
Each of them has the purpose to display a text while storing its value/id,
then send back the Value/id to have it persisted in a db.
I do agree that embedding child documents is a very good way to gain in
performances when storing/retrieving trees, like order and items, or person
and addresses and so on, but in the above case I really do not know how
mongo can be efficently and reliably used.
In real world apps CRUD is 80% of work, and after creating a document I
need to edit it and modify its properties many times during its lifetime,
so I cannot store just the value of a select field, because next time I
have to edit the document I cannot populate reliably a combo and present
the correct selected value based on its description. I have to store IDs.
And here is the question: having tenth of documet types (forms) with tenth
of selects, every and each time I end up with the need of hundreds of
An RDBMS guarantees me that I cannot delete a record if it is referenced
Is this the correct/usual way to do this also with mongodb or there are
You received this message because you are subscribed to the Google Groups "mongodb-user"