Data-driven
Apps and Web Apps

If you are looking to create data-driven software (i.e. software with a database behind it) for use at multiple premises and/or on mobile devices, do you know whether you need:

• a static website,
• a web app, or
• a native mobile app?

This page aims to help you underside the core differences between these, so that you can decide which is right for you.

For the majority of public consumers, a "native" mobile app will be either:

• an ioS app - which is for use on Apple's mobile devices, including iPhones and iPads, or
• an Android app - which is for use on non-Apple mobile devices, including smartphones and tablets, such as those in the Samsung range.

(There are other more unique mobile devices, such as the Blackberry, but these are not the subject of this discussion).

Program code that is written for ioS mobile devices will typically not run on Android mobile devices (though there are exceptions). This is one of the reasons why producing mobile native apps is costly: you need to write program code specifically for each of these two platforms.

By comparison, a web app simply runs within an internet browser and, as a result, just the one web app can be used on most computers and mobile devices.

The differences between "static website" and "web app" are a bit blurry.

Both are "websites" in the sense that they are visited via an internet browser.

One way to draw a line between "static website" and "web app" is to say:

• a "static website" is like a book in that, until a new version is published by the website owner, the content does not change, so every visit to a (particular version of a) static website will reveal exactly the same content;
• a "web app" allows data to be submitted by the user, which is then stored, and will affect what is displayed in the web app in future - either just for this user, or for multiple users.

It is possible to have a website that has a database behind it, even if the users do not modify the content of the database. For instance, if a visitor to a website indicates that they want to see green cars, the website will extract

• pictures of green cars, and;
• information about green cars

from the database, and present these to the user.

This seems to conform to our description of a "static website" because, on every visit to this website, the user will see the same pictures and information about green cars.

However, the OWNER of this website can change the pictures and information relating to green cars by simply changing the content of the DATABASE. i.e. They do not change the website itself, and a programmer is not involved in these changes. What is most likely is that, in addition to the consumer website, there is also a a "web app", just for use by the website owner, via which the website owner can change the pictures and information about green cars (and add pictures and information on other cars, or boats, or whatever).

So, although the consumer interracts with a "static website", the website owner users a "web app" to update the database, which will change the content that the consumer sees if they look up green cars on their next visit.

Because of this blurring of the line between "static website" and "web app" under our previous distinction, we feel that it is better to separate them this way:

• a "static website" does NOT have a database behind it,
• a "web app" DOES have a database behind it.

Others may make this distinction in a different way but, for us, as database specialists, this is a very clear separation.

We can design and construct the database that will sit behind your "web app" or "native app", and we can work with the frontend designers/builders to bring your software online as smoothly as possible.

The picture here of tables and relationships is of course very simplistic.

We've designed and built some very large databases.

• The client reference relates to a project in which the database ultimately had more than 800 tables in it!
• Our OSHatWork^® software, that has been in use around Australia for over 20 years, has over 500 tables in its database.

Whether you need a database with 8 tables, or a database with 800 tables, we will apply the same level of care to it's creation.

We would love to discuss your project, so please do get in touch.