System Concepts
    Overview
    Notification Rules
    Field Layout
    Anonymous / Helpdesk
    Customizations
    Database Myths

 User Guide
    Overview
    Login
    Main Menu
    Notifications
    Creating Issues
    Updating Issues
    User Profile
    Filters
    Reports
    Charts

 Admin Guide
    Overview
    Users
    Groups
    Server Configuration
    SMTP Settings
    Notify List
    Customize Strings
    Default Fields
    Custom Fields
    Field Hierarchy
    Field Control
    Field Order
    Color Coding
    Additional CSS
    Workflow
    Rank / Escalation
    Advanced Features
    Anonymous Access
    Anonymous Email Retrieval

 Setup
    Requirements
    Installing
    Quick Start
    Configuring
    Customizing
    FAQ

Untitled Document

The quickest and easiest way to get a FBT system running is to use our default flat-file system. This system removes the hassles of configuring and maintaining a custom database. This flat file system removes an unnecessary burden since database is really just an application that tailors to operations on a data file. The following discusses some of the disadvantages of having a third party database for storing information.

We understand that some organizations have protocols set up that require systems to maintain a database. We also understand that an advantage to having a database is that it defines a common protocol for retrieving data and writing scripts to analyze data. Therefore, we also offer a Custom Enterprise Solution that we can deploy to meet this need. These systems require custom work and need to be disussed with our sales team.

Clarifying Database Myths

About this article and the author [Chris Justus]

First of all - I work with and use databases almost every working day of my life for the past seven years. If someone were to ask what my specialization was, I would say web-based client/server 3 tier order entry and billing systems - primarily in the Telco space. All of the web apps that I work on use a database for backend data storage. I've used many databases - Oracle, Microsoft SQL Server, MySQL, Postgres, Sybase. All of these serve a purpose, and they are definitely a requirement for most in-house business applications.

What I am claiming, however, is that they are not a fit for data storage for third party commercial applications, and in particular, defect tracking systems.

Why? They are overkill for the storage requirements of a defect tracking system, and in fact, are the root of many problems as they are typically installed / maintained by individuals that are not database administrators that are familiar with the nuances and pitfalls of a particular database.

Myth #1 - Security

What sort of security problems can be introduced by a database? There are several. A simple, and easily resolved issue is that they all ship with and install with default passwords for administrative access - and out of laziness or ignorance, some or all of these passwords aren't changed. Second, they typically open one or many ports, and due to the complexity of the database software, there are invariably security issues. As an example, you can read about Microsoft's SQL Server security problems HERE. Notes about how you should keep MySQL secure are here: http://www.mysql.com/doc/en/General_security.html. Bulletins for Oracle can be found here: http://technet.oracle.com/deploy/security/alerts.htm . This is not to say that any of these databases are insecure, but rather that the administrator of a system must be aware of potential and current security issues, and maintain the installation in a fashion that ensures security - completely acceptable for an organization creating a web application on which their entire business is based, and in which several database administrators are on staff - But this is an unrealistic requirement for tertiary tools (such as defect tracking).

Myth #2 - Performance

Databases are capable or storing, searching, sorting and retrieving millions of records. There core database engine takes a query, examines the structures and size of the various tables being queried, and then determines the means by which it will search and sort the data to retrieve a result set. An application connects to a database, or often will connect many times to a database (connection pooling) to have several connections waiting and ready for the requirements of the applications users.

Myth #3 - Data Stability

A database has an aura associated with it that implies that all of its data is secure and stable. However, a database is just as vulnerable to fire and hardware failure as any other system. In fact, generally it is on a separate system and it is just one more system to worry about.

In our experience, databases are also vulnerable to corruption, security violations, viruses and additional problems. Have you ever tried to get valuable information out of a corrupted database file? In a flat file system, all data is intelligently stored in separate data files that can be read independently. Potential data loss is minimal, and we have a useful backup utility included with the system that does not require you to shut your system down.

Myth #4 - Cost of Ownership

This is the primary reason that our product, Fast BugTrack! Obviously, there are the licensing costs that you have to contend with for brand name systems. However, many people also forget the maintenance cost of any database system. The database needs to be installed, maintained and backed up regularly.

A database also requires a database admin that knows what they are doing. A third party database system requires setup time and there are always instructions that need to be adapted and followed. No database is fresh out of the box.

Bugzilla is a fine example of a free tracking system. However, many of our customers have come to us because the price of that freedom is the time it takes to customize it and connect it to a database.

If you are like most people, every day you make use of a file system on a computer somewhere. The best way to ensure the safety of this data is to make regular copies of the data and store it on a separate system for emergencies.

 

We welcome all questions and comments : bugtrack@alceatech.com

Home | Overview | Features | Screenshots | News
Upgrades | Documentation | Site Map
Downloads | Online Demo
Licensing | Hosting | Extended Support
Alcea | Team | Customers | Contact

Alcea Technologies Inc