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, serverless, reliable, and flexible, SQL database engine. It is particularly favored in the realm of embedded database solutions and small to medium-sized projects. Unlike traditional database systems that operate on a client-server model, SQLite is a serverless database engine, meaning it runs directly within the application it powers. This unique architecture makes SQLite an ideal choice for applications where simplicity, efficiency, and minimal...
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.