The types of databases employed can often determine whether a secondary database is necessary. This secondary database is typically referred to as a staging or intermediate database, because it resides outside the base application.
Should the company “Enterprise Resource Planning” (“ERP”) application support all required business transactions – both inbound and outbound with customers – then the need to have an intermediate database is lessened. However, the company ERP might provide support for “core” business transactions but might be limited for “extended” business transactions. This creates a business problem – where to store the extended business transaction data. Continue reading
It is easy to think of the database as just a place to store data in a structured and sharable way, but modern Relational Databases can do more than that. For example, triggers are a feature that let you define an action to be performed when certain events occur within the database, such as when a new record is inserted, updated, or deleted from a table.
Triggers can be useful when you don’t have control over the application using the database, but you do have control of the database itself. This is actually a common scenario because many application vendors don’t ship their own database; instead, they connect to an existing database and create the tables their application requires when they are installed. This is valuable because it lets you integrate off-the-shelf applications. For example, perhaps you have an application where you normally add and maintain customer information. You also have another application that needs some customer information, such as their name and address for shipping, and it tracks that data within its own table. By using triggers on the insert and update of the address data, you can automatically add and keep synchronized the data for the shipping application. Continue reading