Subject | Re: [firebird-support] Need Feedback on Using Firebird for Element Management Software |
---|---|
Author | Dennis Mulder |
Post date | 2005-03-22T01:07:12Z |
I took the liberty of copying and pasting one of the previous posts of
Dalton Calford of the 3rd of febuary 2005(hope you don't mind Dalton).
What it amounts to is that much depends on how the system is designed
and implemented.
Maybe you want to know if FB is capable of 1000 transactions/sec. I
don't know if there is a number for that, a lot will depend on the
complexity of the transaction I guess. Maybe someone else can help you
out with this one.
Anyway, here's a little feedback for you.
Dennis
[Dalton Calford wrote]
If you are asking, what the limits are, and what platforms does FB support,
then that is easy to answer, but, all things are limited by the final
design
of the database metadata.
You need to understand the needs of the design, then determine how those
needs
are met by the software and hardware, then you must decide if the
implementation will scale to a larger needs environment without a redesign.
This is a very detailed area of design.
We have firebird processing customer calls (over 2 million phone calls a
day)
in a 5 9's environment. That system is replicated in three different
cities
across two provinces. A different Firebird system performs billing
functions - a very detailed process that bills based upon duration and time
of call, also centred around location called from, called to and what
services apply at the time of call for that particular customer. If you
consider the call volume, this should give you an idea as to the
capabilities
of the system.
The billing database also serves the IVR(Interactive Voice Response) units
which allow a customer to dial a number to check their current call
usage and
minutes remaining. The IVR system has to query the database and respond in
under 2 seconds - impressive given the volume of data.
Our CSR's (customer service reps) link into another database that processes
orders, hookups, disconnects, and all other customer related issues.
For backup and other considerations, we have multiple history databases,
that
allow us to generate a historic invoice for the past 6 years. This is used
by the CSR's to view customer calling paterns and build services better
suited to our clients (also it is required by law....)
Our web page is dynamically generated by php and firebird.
Our lines database controlling all the routers, fibre, servers etc is also
used by Firebird and is accessed by custom software on Sharp Zaurus PDA's.
So, can Firebird scale, yes.
Can any Database scale - if properly designed to handle the
shortcommings of
the environment, yes.
Does Firebird ease the design burdon of developing a scalable environment -
very much so.
Please, if you need specific help, ask, overall generalities do nothing but
satify the needs of a marketing dept.
best regards
Dalton Calford
nina_omn wrote:
Dalton Calford of the 3rd of febuary 2005(hope you don't mind Dalton).
What it amounts to is that much depends on how the system is designed
and implemented.
Maybe you want to know if FB is capable of 1000 transactions/sec. I
don't know if there is a number for that, a lot will depend on the
complexity of the transaction I guess. Maybe someone else can help you
out with this one.
Anyway, here's a little feedback for you.
Dennis
[Dalton Calford wrote]
If you are asking, what the limits are, and what platforms does FB support,
then that is easy to answer, but, all things are limited by the final
design
of the database metadata.
You need to understand the needs of the design, then determine how those
needs
are met by the software and hardware, then you must decide if the
implementation will scale to a larger needs environment without a redesign.
This is a very detailed area of design.
We have firebird processing customer calls (over 2 million phone calls a
day)
in a 5 9's environment. That system is replicated in three different
cities
across two provinces. A different Firebird system performs billing
functions - a very detailed process that bills based upon duration and time
of call, also centred around location called from, called to and what
services apply at the time of call for that particular customer. If you
consider the call volume, this should give you an idea as to the
capabilities
of the system.
The billing database also serves the IVR(Interactive Voice Response) units
which allow a customer to dial a number to check their current call
usage and
minutes remaining. The IVR system has to query the database and respond in
under 2 seconds - impressive given the volume of data.
Our CSR's (customer service reps) link into another database that processes
orders, hookups, disconnects, and all other customer related issues.
For backup and other considerations, we have multiple history databases,
that
allow us to generate a historic invoice for the past 6 years. This is used
by the CSR's to view customer calling paterns and build services better
suited to our clients (also it is required by law....)
Our web page is dynamically generated by php and firebird.
Our lines database controlling all the routers, fibre, servers etc is also
used by Firebird and is accessed by custom software on Sharp Zaurus PDA's.
So, can Firebird scale, yes.
Can any Database scale - if properly designed to handle the
shortcommings of
the environment, yes.
Does Firebird ease the design burdon of developing a scalable environment -
very much so.
Please, if you need specific help, ask, overall generalities do nothing but
satify the needs of a marketing dept.
best regards
Dalton Calford
nina_omn wrote:
>
>
> Were planning on using Firebird v1.5.2 as the database for an
> Element Management Software (EMS) product for a wireless LAN
> product. We're trying to find out if anyone out there has used
> Firebird successfully in this type of application. Specifically, we
> will be managing many network elements that will require processing
> a large amount of transactions and want to know if Firebird is well
> suited for this. Does anyone out there have feedback for us on this?
>
> Thanks!
>
>