I need a mobile SQL

envo said:
You would still need to install it on the machine though?
Click to expand...

Yeah... but guys are talking about other software that would need to be installed anyway.... barring SQLite which is just a DLL.
 
Didn't read the entire thread too closely, so not sure about OPs requirement or what the device OS is but here is my 2c.

If the device-side app is on WinMo, then Sqlite on the device is the best option. Here is why:
- You can develop/test/run your mobile app on desktop. You cannot beat that for productivity wrt debugging. Multiple compile/deploy/testrun cycles to device just kills productivity as the deploy is slow and the debugging on device sucks.
- The Sqlite DB on the PC is fully compatible device side. You just copy it to the device.
- Sqlite is a known DB that is used embedded on many devices including iPhone.
- Zero install device side. Just ref a dll and an assembly

I use it in all my WinMo device apps. Not the fastest but it beats the dog's breakfast that is Sql Mobile or whatever it is called nowawdays. What a P.O.S.

For PC side app you have a myriad options. Just depends on the architecture and how the PC app is deployed. The PC side DB choice is completely independent of the device side DB choice. Even if a single user PC app then I still won't use Sqlite. There are so many better and free options. If you want small/simple footprint, use Firebird. You can deploy it as embedded DLL with all the features of the proper server. If you decide to scale up, just deploy the same DB file to the server (even if on the same PC). The server is really lightweight install-and-go. Then obviously you have Sql (Express). A heavier footprint, but if you want to move to the cloud, that is the best option as it is a great stepping stone. You develop against SqlExpress on PC and then migrate to Azure, for example.

Obviously you have to put some thought into how you are syncing data between between device and backend (whereever that is). Personally I use JSON/REST/HTTP for that. Because it migrates perfectly from PC-only to cloud. For PC based REST/HTTP you don't even have to use ASP.NET WebAPI, although better if you want to move to cloud. I have used my own embedded HTTP server for that. Super fast with no install/config like you have to with IIS.

What is your device side OS?
 
Rouxenator said:
If it is a proper RDBMS you need server-side then yes, SQLite is not really that. I do love it however because I hate databases with their referential integrity and stront-procs. SQLite has none of that. Sure you can setup PKs and FKs but whether referential integrity is enforced is up to you. Or at least that is how it was last time I used it.
Click to expand...

Dbms systems like SQL Server, Oracle, MySQL etc., don't force you to use stored procedures, referential integrity etc ?

I have worked on Oracle databases which don't have any foreign keys, stored procedures, triggers.
 
halfmoonforever said:
Unfortunately I can't +1 sqlite because the OP didn't specify the use-case. If the "mobile" needs to sync to some centralized database somewhere so that other "mobile" users can see/access the updated data and pull reports from everyone concerned, then sqlite won't fit in well because it's usually tied to the device that's not syncing to a central db at all.

They also failed to specify if this is a native app on mobile devices, or just a responsive HTML5 implementation. When working with HTML5, you have several storage options, but again, if the client, at any point in time wants to see what Sales Rep 1 is doing, there needs to be a central database to store this in.
Click to expand...

If you sync a mobile device with other systems using web services then it doesn't matter what the local db is. You should never connect directly to a central database from a mobile device. It is really bad practice. I can't imagine any good reason to do this. Perhaps someone else can ?
 
zippy said:
If you sync a mobile device with other systems using web services then it doesn't matter what the local db is. You should never connect directly to a central database from a mobile device. It is really bad practice. I can't imagine any good reason to do this. Perhaps someone else can ?
Click to expand...
Realtime stuff?

Perhaps I'm just a bit slow today, but how else would the mobile device keep in sync if it cannot connect to the central DB?
 
Why would anyone use Express if they can have Postge or MySQL/Maria for free?
 
Thor said:
Realtime stuff?

Perhaps I'm just a bit slow today, but how else would the mobile device keep in sync if it cannot connect to the central DB?
Click to expand...

Think he meant the app connecting directly to a remote DB instead of accessing it through and API/Interface of some kind.

I don't agree with @zippy thought - tt does matter what the local DB is. Consider the usual transaction:

Device -> Interface -> DB

If you have 1000 users you potentially have 1000x the above operation and if the DB cannot handle the concurrent connections something is going to fall over or time out. One solution is to queue the operation and maybe keep it in memory for some time:

Device -> Interface ->
Device -> Interface ---> Queue -> DB
Device -> Interface ->

...but that is hardly ideal (and I speak under correction but that is almost the solution SQLite uses when configured to handle high concurrency).

It also comes down to what you actually need in the database. Consider a share trading system: yes, you need to keep track of intra day transactions and snapshot data but all the live data and portfolios/holdings/market data can be kept in memory. An online shop (or a system like SARS) though hits a database much harder.

There are many clever solutions though and a lot of tech that sets up seamless syncing between databases and other stores. MS SQL for example - somebody enters the country via OR Tambo and the entry is logged to the branch DB server, synced to the central server and down to the CPT branch server in fractions of a second.
 
Hamster said:
I don't agree with @zippy thought - tt does matter what the local DB is. Consider the usual transaction:

Device -> Interface -> DB
Click to expand...

You choose the 'central' DB to serve its purpose for the back-end. I.e. feature set, deployment environment, scalability etc. But that decision and the decision re the mobile database are totally separated.

MSSQL has a compact version for devices and server where the compact version can automatically sync directly with the MSSQL backend database. This is IMHO a total dog's breakfast. A very poor solution.

But we dont know enough abt OPs requirements...
 
Spacerat said:
MSSQL has a compact version for devices and server where the compact version can automatically sync directly with the MSSQL backend database.
Click to expand...

Never knew this... store and forward basically?
 
Hamster said:
Never knew this... store and forward basically?
Click to expand...

Was deprecated in 2013 and is pretty much only maintained via the standard lifecycle policy... when that runs out then its dead in the water.
 
Rouxenator said:
Because SQL Server comes from a proper company with real people?
Click to expand...

Oh, my bad, didn't realise Oracle wasn't a proper company.

M$ fanboys are so biased and uninformed sometimes. There's more to the development world than C# MVC running on ADO.NET on a Windows server using TFS and powershell.

EDIT: And just to take it a step further, companies that use PostgreSQL

Prominent organizations and products that use PostgreSQL as the primary database include:

Yahoo!
Geni.com
OpenStreetMap
Sony Online
BASF
Reddit
Skype <-- OH OH
Sun
The International Space Station <--- HAWT DAMN
Instagram
Disqus
TripAdvisor
Yandex
AWS Redshift


But sure, fsck around with Express because SSMS is runs on windows or something :rolleyes:
 
Last edited:
Hamster said:
Oh, my bad, didn't realise Oracle wasn't a proper company.

M$ fanboys are so biased and uninformed sometimes. There's more to the development world than C# MVC running on ADO.NET on a Windows server using TFS and powershell.

EDIT: And just to take it a step further, companies that use PostgreSQL

Prominent organizations and products that use PostgreSQL as the primary database include:

Yahoo!
Geni.com
OpenStreetMap
Sony Online
BASF
Reddit
Skype <-- OH OH
Sun
The International Space Station <--- HAWT DAMN
Instagram
Disqus
TripAdvisor
Yandex
AWS Redshift


But sure, fsck around with Express because SSMS is runs on windows or something :rolleyes:
Click to expand...

Choose the best product to suit the use case if you ask me.
Only reason I'm suggesting Express is because the OP mentioned SQL Server.... if Express is a non starter then so be it, find the tech that the client is happy with and will do the job.
 
Oracle? More like hOracle. At my previous company we used it extensively since we did a lot of work for Vodacom and at the time Oracle had the best partitioning in terms of performance. But I never liked it. Mikropap does it best.
 
Rouxenator said:
Oracle? More like hOracle. At my previous company we used it extensively since we did a lot of work for Vodacom and at the time Oracle had the best partitioning in terms of performance. But I never liked it. Mikropap does it best.
Click to expand...

Hmm who did you work work? I also worked for company that was Vodacom's main dev house. Used Oracle exclusively.

The benefit of using SqlExpress is that there is an easy migration path from SqlExpress->MSSql->AzureSql
 
I would love to know the use case, if it's just remote clock in and out for 12 people, just find something that already does that, there probably thousands.

If they don't plan on scaling, or using some form of sql then Mau as well use toggl
 
Spacerat said:
Hmm who did you work work? I also worked for company that was Vodacom's main dev house. Used Oracle exclusively.

The benefit of using SqlExpress is that there is an easy migration path from SqlExpress->MSSql->AzureSql
Click to expand...

Swist Group, then it became Altech Swisttech
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X