Hi there, I am evaluating Adalo for the replacement of an old Flash-based app I wrote 10 years ago. I’m trying to understand its database situation and whether or not Adalo will work with what I need to do. I’m currently connecting with a mySQL database.
I have 250 clients. These clients are photographers/videographers. In its most simple form, each client has a unique log in credential. When they log in, they keep track of the personal details of each person they ever photographed… basic stuff like Name, Address, Birthdate, etc. They’ll create new records, update, delete, etc.
If I started building this in Adalo, I would need to make sure that these clients’ user credentials are already in place, and when they log in they can only see their own personal records. In mySQL I have a database for each client, and each database has about 10 tables. They are all the same in structure, but each client accesses their own personal database to manage their information.
How should I link this information into Adalo? Build it brand new in Adalo and manually import all of the records? If so, how do I create 250 unique databases that are all identical yet when a client logs in with their credentials they are directed to THEIR own personal DB?
I’m just trying to get some advice on how to start something as I describe. I would love to talk to an Adalo sales/tech person if need be.
@kmdguy I would approach this differently. Rather than trying to replicate what you have now with 250 individual db’s, I would look at consolidating all those into a single db/app and instead have a collection of photographed subjects that is related to its photographer in the User collection. You could then use visibility rules to restrict it so a logged-in photographer only sees the subjects he/she photographed. If all the db’s are identical you ideally want a script that will export all that data in a common format then have a process for importing it all into your collections in Adalo. 250 CSV’s where the file name = the photographer and then before importing to Adalo you add a column to the subjects table called PhotographerID where that filename populates that column.
If there are never any collaborations such that 2 photographers photograph the same subject then you have a 1-to-many relationship photographers → subjs (otherwise many-to-many).
It would be a super big PITA to maintain 250 separate identical apps differing only by which db they accessed and any new functionality you ever added or fixed you’d have to implement that in 250 places (there’s no concept of syndication or inheritance in Adalo).
So yea, that’s how I would approach it. lmk if that makes sense. Good riddance to Flash
Thanks so much for the answer. That makes sense. I’m going to play around with a very simplistic version to test ideas but I may likely be asking further clarifying questions. In reality, my biggest concern is that the visibility rules are TIGHT. When a photographer has a photo session with a specific person, that person’s record not only contains their name and address and so forth, but also very sensitive information such as Social Security Numbers, Drivers’ License info/pic, Passport information and so forth. So when Photographer ‘A’ logs in to their account, they must ONLY see the models and team that are relevant only to them.
I also believe you could replicate the 250 DB, while it would be a headache, it would be doable. I agree with @grid7 that filters and visibility may be a better way to deal with this, I do understand your concerns for privacy and ensuring the privacy of your users’ data.
I am relatively new to Adalo, so someone should correct me if I am spreading misinformation, but there are no limits to the number of apps you create on the paid plans, just total storage limits. You could build a single app and trial it with one of your clients to iron out the wrinkles. Once you have a solid working prototype, you could duplicate the app for every client. That would create a separate instance of the app for each user.
So visibility rules are for hiding functionality in the UI that should only be for a certain class of people. It’s the relationship property in the collection that yokes the subject to the photographer that will restrict which subjects the photographer can see and that will be bulletproof.
So for example if you wanted to have the ability for subjects to login and update their info you would use visibility rules to give them a limited subset of access to only the functionality they should see (ability to update their profile, maybe view past invoices, etc).
Using the same visibility rules you’d expose functionality to the photographers like adding new subjects they’ve photographed, maybe impersonating a subject to be able to edit his/her info, marking invoices as paid, etc.
But it’s the relationship in the collection that dictates which subjects the photographer can see, not the visibility rule. HTH
Correct there are no app limits that I’m aware of, only storage limits. But just because you can doesn’t mean you should
I think you’re setting yourself up for a nightmare of maintenance if you create the app then replicate it 250 times. There are so many reasons not to do this and the only valid one I can conceive of that would justify doing it is if functionality will be significantly different in each app (but it sounds like that’s not the case and they would be identical).
Strongly encourage going the route of having a single app and just adding a relationship field to the Subjects collection and relating those records to their corresponding photographer User. If there’s a chance you need to support agencies and not just solo freelance photographers then I would encourage you to create a Photographers/Agency collection and relate it to that instead. cheers
100% agree. I have not been using Adalo enough to have really put the relationships and their privacy to the test. I definitely believe this will be your best option.
think about time ;
by just adding a new needed field to a single client DB and Screen could take you 5 min of your time nicely done…
Now, multiply this by 250 times = 20 HOURS !!!
…non-stop no-eat no-popo and no beer !
…so choosing a 1 day painfull work time against a 5 minutes dumb change is only for veeeeeeeeerrrrrrryyyy good safety reasons - and lots of money to pay someone to do it and check it 4 you !
