data structures versus data bases???

[Steve Holden]

"husam" <husalwan at sci.kun.nl> wrote ...
> Paul Boddie wrote:
>
> > husam <h.jehadalwan at student.kun.nl> wrote in message
news:<3BF1163C.9000502 at student.kun.nl>...
> >
> >>ok, now it's clear.
> >>thank you all for your contributions.
> >>
> >
> > But we wanted the half hour argument! ;-)
> >
No, you didn't!

> > I'd distinguish between databases and data structures as follows:
> >
> > A database is a collection of information stored in a structured
> > fashion, possibly along with a description of how elements of that
> > information are related to each other (although that description is
> > really the database meta-data). An example of a database would be
> > "software packages registered at The Vaults of Parnassus".
> >
> > A data structure is a mechanism for storing information. It dictates
> > the interface which lets you add, search for, investigate or remove
> > items of information from the structure. Examples of a data structure
> > are dictionaries, lists, stacks, trees and so on.
> >
> > One might start to argue whether or not a relational database
> > management system (RDBMS) such as Oracle, PostgreSQL, etc. is an
> > implementation of a data structure. Therefore, one could add the
> > following definition:
> >
> > A database (management) system is a system which implements data
> > structures to store information, typically restricting access to those
> > data structures by providing an abstract interface to the information.
> >
> > Therefore, one could regard a database system as being something which
> > potentially implements a number of data structures (in the case of an
> > RDBMS, we could consider a "table" as a data structure) with each of
> > these potentially incorporating other data structures (for an RDBMS
> > table, this might well involve various kinds of tree data structures).
> >
> > Of course, this is a vague discussion of the nomenclature, and out
> > there on the Internet, there's probably somewhere which lists the
> > "official" definitions from the "gods of Computer Science and database
> > theory".
> >
>
> ok, lets start talk about which system is faster?
> imaging that we have 1000000 books. We want to make an interface that
> allow the user to add a book, its location in the library, author,
> publishing agent and year of publishing. Imagin that we make to
> programs, one that stores these informations in a data base system,
> while the other stores the information in simple dictionary. When two
> users search for the same query in these programs, which program will
> retrieve the information faster?
>
Probably the dictionary.

BUT ... unless the two users are going to queue up to use the same program
running at the same terminal, you have to put that dictionary into an
architecture that allows concurrent access by multiple users. If you want to
allow updates (so the library staff can add new books even while the users
continue to look up results) then you probably want the ACID transaction
processing rules. Once you add all this baggage, implementing it yourself
starts to look less attractive than, say, downloading MySQL and using that.

A database is a collection of related data, designed for a known group of
users, to be used in particular applications. This says nothing about its
implementation. A database management system will normally allow database
implementations that offer concurrent access, transactional updates, and a
uniform (hopefully standardized) interface to programs of all kinds.

just-one-man's-definitions-ly y'rs  - steve
--
http://www.holdenweb.com/