There were some complications. For example, you have to upload the dataset into SQLite, and once it's uploaded, you might find difficulties working with it.
A potential drawback is that the database file stored within the application's local storage could be accessible to users. When you build a mobile application with SQLite, the database file is often included in the assets folder. When the app is installed, a folder is created in the device's local storage. In older Android versions, it was possible to access that database file directly from the local storage. I'm not sure if this is still a concern with the latest Android versions like 10, 11, or 12.
There are some difficulties on the server side. When syncing data with databases like SQL Server or Oracle, SQLite requires a kind of double effort. We need to implement business logic either on the API side or within the mobile application for proper data syncing – both when pushing data from the server and when syncing incoming data. It would be an improvement if SQLite could connect more automatically. Right now, there's no automatic syncing approach built into SQLite, so we have to write code to fulfill that requirement. There should be an automated thinking approach in SQLite.
I primarily use SQLite for small-scale applications due to its limitations in storing large amounts of data. For larger-scale projects, I typically opt for MySQL or other alternatives. Storing a large number of dates in SQLite can significantly impact its performance.
The product’s price requires optimization. It could have a user-friendly GUI and better intelligence features. It should be integrated with HADR solutions as well.
SQLite is an open-source database engine known for its lightweight and scalable nature, making it ideal for mobile apps with offline capabilities. Its single-file, server-less design allows easy deployment across platforms, beneficial for both beginners and experts.SQLite offers a straightforward setup, integrating seamlessly for offline storage and local data synchronization. It is widely appreciated for its comprehensive documentation and ability to function without an internet connection,...
There were some complications. For example, you have to upload the dataset into SQLite, and once it's uploaded, you might find difficulties working with it.
A potential drawback is that the database file stored within the application's local storage could be accessible to users. When you build a mobile application with SQLite, the database file is often included in the assets folder. When the app is installed, a folder is created in the device's local storage. In older Android versions, it was possible to access that database file directly from the local storage. I'm not sure if this is still a concern with the latest Android versions like 10, 11, or 12.
There are some difficulties on the server side. When syncing data with databases like SQL Server or Oracle, SQLite requires a kind of double effort. We need to implement business logic either on the API side or within the mobile application for proper data syncing – both when pushing data from the server and when syncing incoming data. It would be an improvement if SQLite could connect more automatically. Right now, there's no automatic syncing approach built into SQLite, so we have to write code to fulfill that requirement. There should be an automated thinking approach in SQLite.
I primarily use SQLite for small-scale applications due to its limitations in storing large amounts of data. For larger-scale projects, I typically opt for MySQL or other alternatives. Storing a large number of dates in SQLite can significantly impact its performance.
The product’s price requires optimization. It could have a user-friendly GUI and better intelligence features. It should be integrated with HADR solutions as well.
It's not a very fast product. The performance could be better. That said, for what we have to do, it doesn't really affect us much.