Application database: Difference between revisions

Latest revision as of 10:22, 12 July 2022

The client’s database is called the application database, and although it is not required, it is doubtful that large systems will do without one. There is no restriction on the the DBMS of the application. It is up to the client to design the application database since the performance/reliability requirements vary depending on the application. Frequently it will be used to store:

Customer data records
Routing information (dial plans)
Client accounts (subscribed features)
Prompts
Call states for HA switchover

Caveats

Database access is usually synchronous. This is not a problem but it should not be overlooked when designing the application database. A lot of synchronous access to a slow database (or on a slow link) can cause significant call delays (not in the data path but in the control path). Using the multi-threaded feature of the CMC library, we can protect a call from another call’s asynchronous operations but we cannot protect it from himself. This can be prevented with good database design.

Return to the Toolpack User Guide

@@ Line 1: / Line 1: @@
-The client’s database is called the application database and is not required even though it is doubtful that large systems
+{{DISPLAYTITLE:Application Database}}
+The client’s database is called the application database, and although it is not required, it is doubtful that large systems
 will do without one. There is no restriction on the the DBMS of the application. It is up to the client to design the
 application database since the performance/reliability requirements vary depending on the application. Frequently it
 will be used to store:
-• Customer data records.
+*Customer data records
-• Routing information (dial plans).
+*Routing information (dial plans)
-• Client accounts (subscribed features).
+*Client accounts (subscribed features)
-• Prompts.
+*Prompts
-• Call states for HA switchover.
+*Call states for HA switchover
+'''Caveats'''
-== Caveats ==
+Database access is usually synchronous. This is not a problem but it should not be overlooked when designing the
+application database. A lot of synchronous access to a slow database (or on a slow link) can cause significant call
+delays (not in the data path but in the control path). Using the multi-threaded feature of the CMC library, we can
+protect a call from another call’s asynchronous operations but we cannot protect it from himself. This can be prevented
+with good database design.
-Database access are usually synchronous, this is not a problem but it should not be overlooked when designing the
+----
-application database. A lot of synchronous access to a slow database (or on a slow link) can cause signigicant call
+Return to the Toolpack [[User Guide]]
-delays (not in the data path but in the control path). Using the multi-threaded feature of the CMC library, we can
-protect a call from another call’s asychronous operations but we cannot protect it from himself. This can be prevented
-with good database desing.