"Andy Dent" <dent.RemoveThis@oofile.com.au.INVALID> wrote in message
news:dent-5EB9B4.15192809042004@news.highway1.com.au...
> In article <0eFcc.80157$vn.236876@sea-read.news.verio.net>,
> "Wayne Warren" <wwarren.RemoveThis@birdstep.com> wrote:
>
> > In my world, where software is developed to solve problems, database
engines
> > are purchased/used if they are a part of the solution. ...
> >
> > seems that many participants define the world the other way around,
where
> > the data model or the theory behind the model assume superiority over
the
> > job to be done.
>
> Most people on this forum argue from the position of corporate-style
> shared databases. It's not often that initial assumptions like that are
> explained.
>
I have come to understand that..
> FWIW I come from an application development background too. The tools I
> use and develop are almost always for a product-oriented application. I
> have very rarely worked with a shared database repository - even in
> corporate settings data has generally been shared by import/export (with
> validation).
>
> Maybe that's why I'm pragmatic and why OOFILE is more of an OO tool than
> a "true relational" database.
>
> I do get sincerely confused about some people's viewpoints however
> because even when I've seen relational databases in use, the
> applications on top are either
> a) dealing with one flat table, or
> b) inherently navigational.
>
> > Is an application "wrong" if it uses a flat file as its database
> Nope.
>
> Nowadays it may be more sensible (and vastly more politically correct)
> to use an XML file.
>
> To give some examples, in the last 6 years I've used XML files for
> - preferences in a distributed 3d Stereoscopic movie architecture, where
> multiple external applications could control QuickTime components to
> adjust 3D rendering on the fly
>
> - preferences in a geological data graphic program
>
> - a label printing application, storing vector objects
>
> - client-server brainwave broadcasting, where XML fragments were sent
> via a BEEP-based protocol to a server to setup triggers, request data
> and XML sent back. The same XML settings schema as used to persist
> settings on disk was used in the network requests to change settings.
>
> As an extension of the flat file argument, there are many applications
> out there where people want to save to a single desktop document that
> can be copied and emailed around, even if internally it is a database.
>
> I don't think you'll find any useful discussion of that kind of
> application on this forum - it should really be named
> comp.databases.object.bigSharedCorporateServers.
>
I am interested in discussing the issues of non-bigSharedCorporateServers.
Is it okay to do that here, or is there another group that is more suited?
It seems like this one is fine, provided the context of the discussion is
understood.
> BTW I came very close to choosing dbVista over c-tree at one point in
> the past, can't remember why I didn't now, although given the changes in
> company direction I'm glad I did as a lot of my work is still on Mac. 
>
Do you mention dbVista because you recognize the Birdstep in my email
address as the successor to Raima?
Birdstep Technology has acquired the assets of Raima Corporation (which sold
itself to Centura Software, now defunct). I'm one of the original authors
of db_VISTA, which became Raima Database Manager (RDM), and is now known as
Birdstep RDM Embedded.
As a Network Model DBMS, RDM Embedded has had many more lives than I ever
expected. Raima tried to obsolete it once in 1994 when Velocis (now known
as Birdstep RDM Server) was released, but that didn't work. Centura tried
to ignore it, but found that it was the only remaining asset to sell in 2001
when they were going down the tubes. Now Birdstep is breathing new life
into it.
Most mentions of Network Model in this or other database groups are
disparaging, and the assumption is that it is a vanquished enemy, defeated
long ago. I am confused about the emotion over the issue.
I don't and won't claim that tools like RDM Embedded are theoretically
superior to relational counterparts. I will, however, claim that Network
Model databases are very useful and viable in the
non-bigSharedCorporateServers marketplace. The reason is that a Network
Model database can be manipulated and queried by small-footprint (Birdstep -
small footprint - get it?) database engines and applications.
Long ago, Raima demonstrated the equivalence between a Network Model set and
a relational primary/foreign-key relationship. So the underlying data
structures in RDM Embedded are not non-relational. A difference is that RDM
Embedded has always been a navigational system, used through an API, rather
than strictly accessible through a relational, non-procedural language.
I don't think that procedural database access is "wrong" either, especially
when a programmer knows exactly what is needed and can code an algorithm
that just does it.
Raima/Centura/Birdstep long since gave up on the bigSharedCorporateServer
market, because the requirements there often preclude a Network Model,
procedural, API-based DBMS.. But there is a flourishing embedded, RTOS or
small-footprint market where it works perfectly. Qualifying it this way, is
there still emotion over the database model?
> --
> Andy Dent BSc MACS AACM
> OOFILE - Cross-Platform Database, Reports, Graphs, GUI in C++
> PP2MFC - PowerPlant->MFC portability
<font color=purple> > <a style='text-decoration: underline;' href="http://www.oofile.com.au/</font" target="_blank">http://www.oofile.com.au/</font</a>><!-- ~MESSAGE_AFTER~ -->
FAQ
Profile
Private Messages
Log in
