What belongs together in a MongoDB document?

A document is one record made of named fields. A collection groups records for the same job. For a repair app, one document can contain the repair’s reference, status and checklist, so the app can reopen them together.

Add validation rules for fields the app always needs. Different repairs can still have different optional notes. Store a shared part catalog separately if several jobs need to refer to the same part and its current details.

A change to one document is applied as a unit. If you also need to change a second document as part of the same action, check the separate requirements for transactions before treating the two changes as one save.

How can you tell that MongoDB saved one repair only once?

Try the steps on paper first. To run them, use an empty disposable database on a private test server with a test-only database account. Before writing, verify the server address, database name and login, and confirm the app has no connection to live records, customer accounts or messages. Stay on paper if you cannot confirm the target.

Make a small practice collection
Use one unsharded collection, with its records kept together in this practice setup. Add a rule requiring a checklist. Use each job reference as the document’s _id, the identifier MongoDB requires to be unique in this collection.
Save a dummy repair
Use reference TEST-17 with a checklist containing “inspect cable” and “confirm power”. Read it back and check both items.
Submit the same reference again
Try a new document with TEST-17 and a different checklist. Confirm the duplicate is reported. In a fresh read, confirm the original checklist stayed the same. If the reply is uncertain, look up that identifier before you try again.
Try a different kind of repair
Save TEST-18 with its own checklist and an optional screen-size field. Try a new test reference without a checklist and check that it is rejected and absent on readback.

Who runs the database and who can read a repair?

MongoDB Community is a server you can manage yourself under the Server Side Public License. MongoDB also offers a commercial self-managed edition and Atlas, a managed database service. Confirm who handles upgrades, storage and recovery for the option you choose.

Give the app server a restricted database account and keep its credentials away from the browser. For a remote database, check allowed network access and verify the encrypted connection. Customers sign in to your app. Its code still decides which person can open a repair or change its status.

What should you check before picking an Atlas plan?

Atlas tiers have different storage limits, billing and recovery options. The Community server license and the Atlas service bill cover different things.

What to look up for the database you will actually use
Option	Which cost or recovery details matter
Self-managed Community	Allow for server capacity, lasting storage, backups and time to operate it.
Atlas Free or Flex	Check data and index storage limits and the backup options available to the chosen tier. On Flex, your workload in operations per second determines the hourly rate. Those hourly charges add up on the monthly bill. Verify what you can recover before putting live records there.
Atlas Dedicated	Check the hourly cluster price for your capacity, provider and region. Storage, backup and network usage can affect the bill.

Which MongoDB export could you use to recover an app?

For a deployment and collection that support it, mongodump creates a database export with documents, collection settings and index definitions. mongorestore can reload supported data and rebuild the recorded indexes. Use JSON or CSV from mongoexport to share selected data. Keep the binary dump and its metadata for a restore that needs collection settings and indexes.

Check compatible server versions, access and export options before you rely on a dump. If people keep making changes during the export, verify how your setup captures those writes. Atlas Free and Flex restrict restoring the admin database, database users and roles, and replaying the change log through mongorestore.

For practice, use only the sample dump from this exercise. Before restoring, verify the server address, database and collection names the restore will use, and the test-only login. Use an empty, disposable MongoDB deployment separate from your live cluster. Keep live data and services disconnected. Stay on paper if you cannot confirm the destination. Restore the sample there and read TEST-17 with its original checklist. Confirm the validation and duplicate rule still work. Recreate any needed app settings, database access and network controls, and account separately for app sign-in and uploaded files.