This is just an Idea I would like to share.
Your backend service has really everything any app would need and your support is amazing.
I think introducing an RDMS as an alternative to NoSQl would be a great asset for many apps who need more relationship style than big data. It could be an option to sign up for or a product to choose. This would make you one of the very few backend solutions to provide this capability as many (including firebase) provides only NoSql.
With your structure already in place, I don’t think it is major change to add the capability of MySql or another flavor of RDMS
Just a suggestion for future. : )
Thank you for the suggestion. Our database from a client view is now rather an ‘object-oriented database’ than a NoSQL one in a sense of MongoDB or Firebase database. But what’s important is than contrary to other mBaaS providers, we use MySQL under the hood. Basically, our Data Service provides the mapping between the object-oriented view of the database the client works with and the relational structures used internally.
We chose the object-oriented view of the database because it’s much more natural to work with than SQL or NoSQL: you only have objects and relations to other objects. You don’t have to mess with documents and complex bindings between them like in most NoSQL or with additional tables used to implement many-to-many relations and foreign keys in SQL databases.
We would be glad to hear the description of your specific use-case where you think you need relational database, and I’m sure we could suggest how it could be solved much more easily and obviously with the existing view of the database.
Sorry for the late response. I appreciate your explanation. I suggested Mysql because a lot of time an app might be dependent on heavy relationship where I dont find the object oriented view solves it. Actually I just asked a question 2 weeks where the use case was not met using the object oriented view. Let me give you a simplified example where I can’t seem to meet the requirement.
Lets say we have 3 tables
-Room table where users can have post rooms for rent.
-Availability table where it has the room availability posted by the user (say Mondays availability, Tuesday Availability and so on)
-Booking table where the bookings are made against a room.
The Room table has 2 one -to- many relations ships to Availability and Booking, call them Column A and B.
Now here is a use case whereI cant seem to find how we can meet.
I would like to get all the rooms who has availabilities on monday and who has bookings made after todays date. However, I need the availabilities and the bookings matching that condition to be returned as well.
In sql (pseudo code), you can simply get that as follow
select * from Room, Availability, Booking where Room.id = Availability.id AND room.id =booking.id and Availability.day = ‘Monday’ and booking.fromDate > Date(now)
In backendless, when you do the query with the conditions on relationship then you get the right rooms but ALL it relations. You can’t get the relations that match the condition specified.
As you can see, this is an essential part of any JOIN operation where you need the results returned from all the tables based on the conditions passed.
Do you think you have a solution for this using backendless?
What’s happening now is that I get all the relations and in the Java code I filter the ones I don’t need (which kind of defeat the purpose of a query when you have a lot of data)
So basically all you need is filtering the related objects’ properties? Same as current ability to filter the parent object’s properties via DataQueryBuilder.setProperties(…) method, but for relations, right?
Great, because it can easily be handled without any SQL JOINS or anything complex from your side at all. This is not the first time we see this feature request, so we’re already planning this extension to our DataQuery. Presumably, you will be able to filter related objects’ properties by specifying them exactly as you specify properties of the parent object now (e.g. “address.city, address.zip” wll load only 2 properties in relation “address”: “city” and “zip”); and also instead of just specifying “address” in relations list (which essentially will load all related addresses) you’ll be able to specify a where clause to define which related objects should be loaded.
Hope this gives you an understanding of how you’ll be able to adapt it to your exact use-case.
This said, stay tuned for our announcements and you’ll be the first to know when this additional functionality is available!