I am trying to create a workout app api using express, and mongodb. I plan on creating a list of exercises so the users can see all of them on the app, but the exercises can also be part of a workout created by the user. Users could also add their own exercises, but these will not be added to the default list of exercises created by me. My question is. If an user is creating a workout, how do I add an exercise from the exercises list database to their own custom workout. I am sorry if this does not make sense, please ask me any questions and I could clarify more.
At a high level, I would suggest that you create a database for all standard workouts that you have. Besides that you will create a database for each user in which you can add the custom workouts that he/she choose. Databases will have the exercises as records.
Related
I am trying to build a full stack application that can remember specific properties when users are logged in. I want to incorporate a database(mongoDB). When the users are logged in, I want the users to be able to add their favourite food items.
As for how I would develop something like this, I am a little bit confused on the back end of things. I just want to make sure my method is appropriate before I start writing code.
As of right now, I am able to add new users to my database, but to remember what a specific users favorite food is, would I just modify the existing database for that specific user?
For example, if I had user A and B and if I add new food to User A, would I just add new food items to the key-value pair associated with user A? Would there be a better way to do this? If it helps, I will also be using node and express. I did read online that I could use cookie session in express, but I want to get familiar with databases.
Thanks!
Your method seems like it would work, but it's hard to say without knowing the full use of the "favorite food" feature. If you're just trying to have some text in the user's profile that says "Favorite Food: Pizza and stuff" then your approach is simple and it works. Don't use cookies/sessions if you want to store this information permanently. If you're trying to match users to other people with the same favorite foods or you have a preset list of foods the users must choose from, then you might want to consider other database schema.
I'm not too familiar with MongoDB, but I do know they pride themselves on being ~different~
Check out this article from MongoDB, as it seems to explain some different database approaches and MongoDB features and their pros and cons.
Good luck!
I'm working on a SwiftUI app that connects to a MongoDB Atlas database (hosted) which is populated and managed by a server. I've created a Realm for my SwiftUI app, and can sucessfully create a user and log-in, but I'm having trouble connecting the created user (found in App Users in the Realm UI) to a user document in my database's User collection. Whats the proper way to do this? Do I need to manually create a user in the collection for any new app users?
#jostell13 - REALM users are not ATLAS DATABASE USERS.
However, this does not mean that REALM users need their own collection for any new app.
When you create a realm app, you specify the ATLAS cluster it is associated with. There are multiple ways to do this - I'll go over two. SDK, Functions
https://docs.mongodb.com/realm/sdk/swift/examples/read-and-write-data/#read---write-data---swift-sdk
https://docs.mongodb.com/realm/sdk/swift/data-types/collections/#collections-are-live
The SDK provides LIVE collections, which is a really awesome capability. If LIVE collections, and things like real-time notifications, live updating objects, lazy-loading objects etc are not a requirement, you could also consider functions.
(Credit to #Jay for bringing up SDK > Functions)
https://docs.mongodb.com/realm/functions/
const plants = context.services.get("mongodb-atlas").db("example").collection("plants");
const plant = await plants.findOne();
return JSON.stringify(plant);
Functions can be called from the REALM app, or you could even create things like HTTPS endpoints so you can interact with functions using simple HTTP requests. https://docs.mongodb.com/realm/endpoints/
The best part about functions is - DEPENDENCIES! You can literally use almost any npm module as a dependency for your functions! (There are some limitations, but this featureset will only be improving in the future)
https://docs.mongodb.com/realm/functions/add-external-dependencies/
While I got a lot of useful info from the responses here, the solution I found was not mentioned.
The correct way to do this is still to do a manual copy of data from the Realm to the database via a triggered function.
I am creating a mobile app , and this mobile app works currently with one google fire store database.
I want to see this app to more than one customer and I don't want to make a collection for each customer.
Instead I want to open a new database.
I know that I need to import the JSON file for each database.
My Question:
Can I tell the app to use database one then if you login with another
account use database 2?
There is only a single Firestore database instance per Firebase project. There is (currently) no way to add additional Firestore database instances to a project.
So that means you'd have to have a separate project for each user. That part is technically feasible for databases, as you can dynamically create a FirebaseApp instance with the configuration data for the signed in user. The problem is that you need to first sign in the user (which requires that you already have a FirebaseApp instance for the project that this user is registered on.
I'd highly recommend reconsidering why you want to create a separate Firestore instance for each user, as creating user-specific sub-collections is by far the simplest way to implement a multi-user application on Firestore.
I’m a fresh starter with Realm Swift. I did some sort of Realm graph object (seems to work for most people) and a UI mockup to explain you what is the problem with my current design.
An example of the UI workflow
The user accesses a list of workouts he created and selects one.
The user starts a training session based on the selected workout.
The user finishes the workout and then gets the summary page.
Later, the user can access a list of past training sessions.
The user can select a specific session to see how it went.
Realm graph object representation
My current issue
My problem with the current graph model is related to the 'TrainingSession object' where I need static data to generate charts and statistics.
The WorkoutSession object has relationships with objects which contain dynamic content, since I can do the following:
The user can delete at anytime a workout or change its name, etc
The user can add or delete an exercise within a workout
By changing a workout or its nested objects (exercises, sets, etc), it will change the information displayed in a training session (screen ⑤). E.g.:
Remove pushups in screen ② for Workout A.
Check a specific session with Workout A in screen ⑤, then pushups will be removed.
Approaches
I really don’t know how to deal with it? As you may guess, I’m trying to reduce data duplicates, so I came with solutions such as:
Duplicating all related objects to the workoutSession (Workout, Exercises and so on), but if I do that each time I create a session, it’s going to be huge.
Creating some sort of workout/exercise versioning system, so the training session always refer to a specific version of the workout/exercise. A workout is actually working like a blueprint.
I hope my visual explanations are helpful enough. If you feel you need me to add some realm code, I’ll do it (but I can’t share the project I’m working on).
Thanks in advance for your precious help ;)
I'm trying to model a simple, experimental app as I learn Symfony and Doctrine.
My data model requires some flexibility, so I'm currenty looking into the possibility of using either an EAV model, or document store in MongoDB.
Here's my basic requirements:
Users will be able to store and share their favourite things (TV prog, website, song etc).
The list of possible 'things' a user can store is unknown. For example, a user may want to store their favourite animal.
Users can share their favourite things with other users. However, a user can decide what he / she shares with each other user. For example, a user may share their favourite movie with one user, but not another.
A typical user will log in and view all the favourite things from their list of friends, depending on what his friends have decided to share. The user will also update their own favourite things, which will be reflected when each other users views their own profile. Finally, the user may change which of his friends can see what of his favourite thing.
I've worked a lot with Magento, which uses the EAV model extensively. However, I'm adding another layer of complexity by restricting which users can see what information.
I'm instantly drawn to MongoDB as the schemaless format gives me the flexibility I require. However, I'm not sure how easy (or efficient) it will be to access the data once it's saved. I'm also concerned about how changes to the data will be managed, e.g. a user changes their favourite film.
I'm hoping someone can point me in the right direction. This is purely a demo app I'm building to further my knowledge, but I'm treating it like a real-world app where data access times are super-important.
Modelling this kind of app in a traditional relational DB makes me sweat when I think about the crazy number of joins I'd need to get the data for one user.
Thanks for reading this far, and please let me know if I can provide anymore information.
Regards,
Fish
You need to choose a model based on how you need to access the data.
If you just need to filter out some values when viewing the user profile, a single document for each user would work quite well, with each favorite within that having a list of authorized user/group IDs that is applied in the application code. Both read and write are single operations on a known document in this case, so will be fast.
If you need views across multiple profiles though, your main document should probably be the favorite. You'll need to set up the right indexes, but performance shouldn't be a problem.
Actually, the permissions you describe don't add that much complexity to an EAV schema - as long as attributes can have multiple values the permissions list is just one more attribute.