Database Reference
In-Depth Information
We chose iCloud for this solution because of its simplicity and ease of use. We could've looked at
other cross-platform or MySQL databases, but when not looking at data on different devices, and
exclusively in the iOS atmosphere, we felt iCloud was the best solution.
When a manager looks at a report, such as a grocery aisle report of sales over the past seven
months, he can easily close that application, put his iPad back on the charger and then save the
data. Once he gets home he can pick up his iPhone and all that data is available to him. Once the
app syncs with the iCloud, the documents that were created for the data were automatically saved
by him and categorized based on their user account.
Case Study of Azure: Grocery Store Customer Application
We can develop apps specifically for the use of customers. These apps have the ability to integrate
directly with the Storm applications. Options include allowing customers to make shopping lists
of items in the database, or when used in tandem with the Stock app, allowing them to preorder
specific items so that stock employees can have them ready when customers arrive at the store.
As this topic is being written, we are about 8 to 12 months into the cycle of an Azure SQL database
and what that service offers. We talked about some possible scenarios, but one real-life scenario
takes place in the Customer app in our grocery store suite of apps. The primary reason we chose
to use this database is because the Customer app needs to be cross-platform. It's not possible for
the grocery store to reach everyone who they want without a cross-platform app. The app needs
to support not only Android and iOS, but Windows 8 as well. This is a spot where Azure has a clear
advantage over iCloud's SQL database and a standard MySQL database.
We created a customer application that has backend database connections. In this customer
application we feel it would be good to have a customer loyalty program. We want to keep track of
the user interactions with the database and push notifications to regular users to send them special
offers or other information based on their user's information within the database. If we know a user
suddenly begins adding baby formula to her grocery list, perhaps we try to find a way to send her an
ad for diapers her next time in.
There will be many other functions of this customer application, many of which will require restricted
access to the grocery store's data. The customer can make lists of items specific to her store, and
she can even preorder small, select orders and have them ready for pickup. This means that when
the Manager app updates the database, deciding which items are available for a pickup order
(maybe one night it's the ingredients for a spaghetti dinner), this information is displayed on the
Customer app. Once the user decides she wants the spaghetti dinner, and she creates an order for
pickup, that information is then pushed to a new table in the database. The Stock app is then on
the lookout for that new table to be updated in the database. When the app sees that a change has
occurred, it pulls down that data, allowing the employee to gather the ingredients and have them
ready for the customer when she pulls up.
Because we have three platforms to cover with the Customer app, iCloud is not going to work, but
MySQL is another option, as is Backend as a Service offering such as Firebase, or another SQL
store such as PostgreSQL. Writing an API to connect to these mobile services from each one of the
devices is certainly manageable. Currently, we're using MySQL in this scenario for users to access
the database from the customer application. We will be moving into it as your database because of
the ease of service and the tracking capabilities and the fact that it has built-in reporting.
Search WWH ::
Custom Search