Database Reference
In-Depth Information
Microsoft has taken a look at the back side of the API connections and really gave developers a
great opportunity to manage the services closely. When we talk about connections or concurrent
connections, we're talking about APIs. These may need to be adjusted from time to time to allow for
greater traffic or increased growth from what is, in essence, the building of your business.
Case Study of MySQL: Storm Point of Sale Application
The Storm POS system features a sleek and intuitive design and extensive functionality developed
for mobile tablets. Sure to impress customers at checkout, the tablet can be paired with great
peripheral hardware solutions such as receipt printers and cash drawers, or may be integrated
with existing hardware. It can also be customized to a company's brand and image, creating a
piece of software unique to its establishment. The basic Storm solution gives the POS software the
functionality to connect to a database, scanner, receipt printer, cash drawer, credit card processor,
and Manager app, with the option to add connectivity to several other devices and peripherals.
With the grocery store database, we create a database on the cloud so that the Manager app can
access that data, as well as the POS application. The POS is the brains of the transactions. The
Manager app is the brains of the modifications and reports. The software is working to perform its
functions and update inventory while the Stock app is pulling inventory. The database Manager app
has to read endpoints to that data in the cloud. All three applications are essentially reading and
writing from the same database.
Once the applications are online and accessing the database API in real time, we write SQL
statements to supply the data for subsequent calls from that connection. We also want to make sure
that we are connecting and addressing that data based on the cache set up to allow for smooth user
experiences. Because this application is mission critical, we never want to lose data, even if we lose
a connection.
With the SQL Server we can accomplish a lot more, especially when using very robust data streams
and a strong GUI that's doing business. Simply saving key-value data wouldn't be the most
straightforward or quickest way to read/write but because we are connecting with the database on
the devices connected, it stores a version of the database so that it is actually utilizing some of the
database functions internally. We cache the data for an upload later, depending on the connection
speeds of the location. This is so the app can operate online as well as offline. The data is still
coming from the server on initialization. We mentioned this before, but we are actually going to use
iCloud with the Manager app, but the POS application is server driven and uses a MySQL database.
 
Search WWH ::




Custom Search