Documentation
Home Evaluation Summary for programmers Product limitations Goals of Axisbase Quick start Installation Using the launchpad and opening databases Connecting to a sample database Using building blocks Planning Define the purpose Define the requirements Borrow existing work Determine the architecture Design the data model Design the process model Deploy and maintain the product
Tutorials
building blocks
Performing a mailmerge Bulk e-mailing
Programming
Single-threaded progress indicator in c#
Reference
Database menu items
Import XML Save Copy As Integrity Check Change Password
Database Properties window
Opening the database properties window Record types tab Display types tab Roles and Users tabs Sidebar tab Database ID/Links tab Counters tab
Building blocks
Building blocks window Editing grids and cells Hyperlinks and nesting Data Subset window Data Outsource window List window Window window Report window Bulk Operation window Label Printer window Choosing a data source
Special topics
Expression syntax Browse records Storing building blocks within other building blocks Programming Using custom code in building blocks Using Axisbase as an embedded database Axis1.Util namespace reference Axis1.Data namespace reference (Fishnets) Axis1.Data namespace reference (other) Axis1.Forms namespace reference

Determine the architecture

Software architecture is about the pieces and how they connect. It includes the major choices of tools, such as the language or database system to use, and whether it is a web, desktop, or mobile application. There is often more than one architecture that would meet the requirements, so the best choice is usually the simplest one. The architecture of most projects can be explained and diagrammed on one page.

Basic questions answered by architectural choices

The architecture should answer these questions:

  • Where do all the data live? Is the database hosted by an ISP (internet service provider) or on an office server? (If there has to be more than one database, why?)

  • Are there non-trivial configuration files?

  • Are any of the pieces able to work off line (not connected to the database)?

  • What tools and programming languages are used to create the solution?

  • What components are required for deployment (on the end-user's computer)?

  • How will backups work, and where will they be stored?

  • What old tools and files will be replaced by the new system?

If you already know that you will be using Axisebase without any programming, then your architectural choices boil down to one main question: where the database is hosted - either in house or at an ISP.

Examples

Here are two examples of architecture choices for a software project:

1. In-house with public web access

 x

2. Database and web hosted by separate ISPs

x


Multiple databases with Axisbase

There are several cases where you might want to use more than one database file. Axisbase supports this by linking files together so you can use all the data and building blocks in one file from another file.

  • Use one file for the company data, and another for the visual building blocks. This allows someone to work on building blocks off line, then replace that file, without touching the data file.

  • Use a data file for reference data, like the list of US States, or companywide codes. Then when you need to do a project for a specific department or job function, it can use the company reference file without having to make a copy of the reference data.

  • Post file(s) on a server for basic users, but allow power users to create their own files on their own PCs that use the served files. Power users can then create their own building blocks for special functions, and save them without making any changes to the companywide database files.

(c) 2014-2015 Divergent Labs, Inc.