I know the difference between centralized and distributed databases but I
can't find info on which type is used by which organisations.

For example when I think of a bank I would expect them to use a distributed
database since they could have one file for each branch or sort code.

The amount of processing a bank is required to do would make a centralized
database too slow. However .. even though it is a distributed database it
must worked a centralized database in that updates must be recorded in all
of the relevant databases immediately to avoid fraud ...

Organisations using centralized databases might include airline booking
systems ..... this must also require bullet proof network connections ..
mind you maybe not .. the airlines don't worry about overbooking do they?

thoughts please

"code_wrong" <tac (AT) tac (DOT) co.uk> wrote


It depends. I can see a bank using a central db. It would make transfers
between accounts (eg savings and checking) much simpler. A customer doesn't
want to have hassles transfering money because he opened a checking account
at one location and a saving account at another location. Banks would use a
mainframe class machine for a large bank.
Jim

"code_wrong" <tac (AT) tac (DOT) co.uk> wrote

I think that's changing now. In the past organisations used distributed
databases. Now, for the most part, they are centralised as hardware has
come a long way and there is a requirement for online banking.

To ensure scalability, application processing is performed on seperate
machines and only the database transaction is committed via the database
server.

AMO

code_wrong wrote:
In the US most of the major banks use centralized databases.
Typically (in the US) updates are run as a nightly batch and
deposits are not credited to the account until the nightly batch
run. (Withdrawals are deducted immediately). On weekends
things are even slower for example, both the deposits and cash
withdrawals I make from an ATM on Friday carry a Monday date on
my bank statement.

By the way, a properly designed centralized database with
sufficient hardware isn't too slow to handle the transaction
volumes of even the busiest banks in the world. It may require
dozens of processors and hundreds of disk drives, but hardware
is cheap.

When your database can be accessed and updated from thousands of
locations, most of which belong to other companies, only a
centralized database will work. The first airline reservation
system was Sabre which IBM developed for American Airlines 40
some odd years ago. It allowed any American Airlines location
and any travel agent with a Sabre terminal to access and update
the system. It served as the model for the world's reservation
systems -- a centralized database accessible from anywhere in
the world by anyone with a valid account and password.

HTH

Jerry

code_wrong wrote:
I agree with others comments contradicting your assumption of a
centralized database being too slow.

information for that cell while the central DB maintains plantwide (and
company wide) resource availability and production. A smaller factory
might control all workstations from a central machine.

Yes, the robustness of communications links and of servers does
influence the decision. If your distributed sites are all within one
building where you control the communications (laying wire for example)
then you might prefer a central machine controlling all sites, unless
the number of production interupptions of that central machine exceeds
some limit (hey you got to bring the server down for maintenance
sometime!). At that point a distributed model might fit (ie, central
machine is down, but each site can continue in batch mode to synch up
with central later)

Consider that even vending machines maintain a simple DB of sales and
inventory

So it is not a DB issue that can be considered in isolation.

Other factors?
Scalability - does the structure allow the company/system to
grow/shrink as needs change?
equipment costs - not always easy to measure between designs.
regulatory requirements - e.g. a device may be required to maintain a
local DB of QC results so they can be reported independently of a
central server. but they are also copied to the central server for
other QC purposes.
mobility - for example, insurance salesman needs the data for his
clients locally on his laptop (at least this was an easy call until
cell phone providers started offering wireles broadband connections)

business requirements - what the boss says goes! He's paying for it!

Bottom line: This is not just a yes/no question

Ed