Database design on IOS - flatten or normalised?
Hi, following on from my earlier question:
https://www.experts-exchange.com/questions/27847640/ASP-net-webservices-in-IOS-how-to.html
but on a different topic:
I am looking at writing an IOS app that gets data from our in house system and allows the user to download the list of jobs for the day, add completion details, etc and upload the details back to the live server.
Of course that’s the simple outline – there are a lot of tables and data required to do this. the job itself is made up of multiple tables, and there are other entities, such as parts used, time spent, etc that is collected for the job.
The data structure is quite complicated. With SQLLite as the local DB on the IOS device, is it best to replicate the DB schema in SQLLite or “flatten” the structure as much as possible for SQLLite.
I’ll still need a fair few tables – the main job, parts, timonjob, etc… but should I flatten the data from the related tables for the job into a single table? I wont be updating the job itself just viewing the details so instead of having say 4 (there are more in reality!) tables
Call
Call_priority
Call_status
Address
Should I create a different call table structure on the IOS device which has the relevant fields from the real call table structure, plus the lookup values from the other 3 tables?
Also what is the best way to get data from and to SQLLite from SQLSever? I was looking at doing it via webservices. Are there any better methods? I find it quite hard to find specific stuff abot best practices for data, etc on IOS…. The books on amazon tend to be introductions, then either game or interface heavy with little about data
https://www.experts-exchange.com/questions/27847640/ASP-net-webservices-in-IOS-how-to.html
but on a different topic:
I am looking at writing an IOS app that gets data from our in house system and allows the user to download the list of jobs for the day, add completion details, etc and upload the details back to the live server.
Of course that’s the simple outline – there are a lot of tables and data required to do this. the job itself is made up of multiple tables, and there are other entities, such as parts used, time spent, etc that is collected for the job.
The data structure is quite complicated. With SQLLite as the local DB on the IOS device, is it best to replicate the DB schema in SQLLite or “flatten” the structure as much as possible for SQLLite.
I’ll still need a fair few tables – the main job, parts, timonjob, etc… but should I flatten the data from the related tables for the job into a single table? I wont be updating the job itself just viewing the details so instead of having say 4 (there are more in reality!) tables
Call
Call_priority
Call_status
Address
Should I create a different call table structure on the IOS device which has the relevant fields from the real call table structure, plus the lookup values from the other 3 tables?
Also what is the best way to get data from and to SQLLite from SQLSever? I was looking at doing it via webservices. Are there any better methods? I find it quite hard to find specific stuff abot best practices for data, etc on IOS…. The books on amazon tend to be introductions, then either game or interface heavy with little about data
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Although it's not a technically complicated idea its's just identifying the "way apple want you to do it" for IOS.