"Andy Dent" <dent (AT) oofile (DOT) com.au.INVALID> wrote

consider this part of embedded)

I would think the posters in the 1) category are numerically, small, but
great in arrogance and vitriol.
--
<disclaimer>
Opinions posted are those of the author.
My company doesn't pay me enough to speak for them.
</disclaimer>
--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&S
(303) 971-3846

Jim Melton wrote:
I would not always consider this (4) "embedded," if only for the
reason that "embedded" has the connotation that it
is on a relatively small processor with a relatively
small memory and (possibly) not even a local disk.

One of the projects I am currently working on
uses a 12-way Sun box with 96GB memory and a couple
of Raid arrays with 12*73 GB disks in the arrays.
That is hardly an "embedded system," but we do have
persistence requirements thus we use a commercial
database system to do the persistence for us since we don't
want to reinvent any octoganal wheels.

Very well put, Jim!

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

alfredo (AT) ncs (DOT) es (Alfredo Novoa) wrote
writing a system that records and broadcasts brainwaves and a former
employee who's now working at a company who have a GPS product and
struggle with the processing overhead of SQLServer in the background.

"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote

you are wrong to say that it was discarded years ago. It is still being
used by thousands of programmers who are creating applications for which
this type of database is entirely sufficient. They are using it because of
issues already discussed in this topic, and we agree that they are from a
different world than yours. The Raima/Birdstep Network model database
engines have historically been chosen for practical reasons - usually cost,
footprint, or availability on their platforms. There's also database
factors which are independent of model, such as ACID support, multi-user
support, heterogeneity or administration, which are more important to the
developer than the underlying data model.

Years of Relational: Relational Really Is Different
(http://www.intelligententerprise.com...1105/online2.j
html?_requestid=170740)

"In other words, the information that was represented by a foreign key in
the relational design is represented by a link in the network design; links
are the network analog of foreign keys"

I am taking this quote in-context. While I admit that Date's article is
negative toward the Network model, he shows this equivalence to demonstrate
that a relational model can represent everything a network model can. Yes,
that's true. But contrary to what Date says, the non-essentiality of sets
does not render them useless.

Since sets are a simple data structure, they are a useful concept for
creating databases with a lot of complex structure, which may also be
operated on by a small and efficient database engine. This works, and it
works in small spaces.
"primitive" concept above. But to "program in machine code or using wires?"
I believe you are exaggerating just a little bit here. And I'm not sure
quite why. You have no argument from me that relational theory covers
everything. But I think the programmers who have used both Relational and
Network model databases would not support your extreme analogy.

Wayne Warren wrote:
He definitely does not show equivalence. You are simply playing word games. Date says
'analog' not equivalent. Yes, you can map network links to relational foreign keys, but
the reverse are not true. Some of the differences are - network links are
uni-directional, brittle and based on physical artifacts instead of values in columns.
The differences are enormous.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

"Lee Fesperman" <firstsql (AT) ix (DOT) netcom.com> wrote

....
"equivalence" incorrectly, but I'm not trying to play word games.

Actually, I don't want to make a case that Network model is an alternative
to Relational. They are at two levels, with Relational being the
higher-level model. The Network model is simpler and smaller. When you
mention "uni-directional, brittle and based on physical artifacts" you are
talking about implementation, which I think is a different discussion. Our
products have bi-directional links. Brittle is subjective and based on the
quality of the product, not the concept. Can an index be brittle? Physical
artifacts? Yes, network links can be and usually are physical pointers
directly to another record. Can you get anything more efficient than that?

Efficiency, simplicity and small-footprint aren't at the top of all priority
lists - but they are for some. To get those qualities, you need to
sacrifice functionality. Isn't that okay? Isn't that a trade-off that
application developers can make for themselves?

Wayne Warren wrote:

[SNIP]

You folks are obviously from two different sets of experiences
(I was going to say "worlds", but someone may interpret
that as a pejorative.)

In the world of corporate data repositories, a query
such as:

"Show me all the sales of Tylenol throughout the state
of Texas by Walmart store and sort it by date" is not
unusual, but it is not something I would specifically
code for. But it *IS* a very useful query for some
people. (If there'a a flu epidemic, Walmart wants
to be sure there is ample inventory on hand, and it
wants to make da*n sure that it isn't on sale!)
This sales/inventory database may also be part of
a larger corporate database which include accounts
receivable, accounts payable, etc. ("What do we owe
J&J for the month of March for Tylenol?")

On the other hand, there are applications which use
databases (let's call them data "stores") for the
simple reason that they need the data to perform
their task, and NOT to support some kind of
corporate-wide intelligence gathering network.
(There are, of course, issues about how current
the data is. Most applications in my experience
do not need "up to the second" data.)

This datastore (IMO) should *not* necessarily be subject
to the same rigorous treatment as in the corporate
datastore is subject to.

If a network-style database meets the requirements,
there should be no recriminations about their
choice of database structure and choice of implementation.

All too often, this is not the case.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

I've had opportunity to work with relational databases and network model
databases. The network model database was developed in response to CODASYL
and provides superior performance to the use of indexes for table joins.

The grammar for the SQL DML works well with network model and hybrid
architectures. To suggest that using SQL inside applications makes
application development easier is contradictory to my own experiences.
Embedded & dynamic SQL are very tough to program with as compared with
native language DML such as available with RDM.

To suggest that network links are "brittle" does not provide sufficient
information to understand what is meant. Certainly doubly linked set links
contain redundancy. Remember that all tuned databases contain redundancy
for performance reasons; an index is a redundant data structure.
Operationally, such redundancy was not a problem, in my experiences. I do
not believe it to be a serious concern with today's robust DBMS's, Windows
notwithstanding. The reliability of the host file system, hardware and
operating infrastructure is of paramount importance for a host of reasons
aside from ensuring integrity of redundant data.

I believe that the point Wayne W is making is that for many projects, the
database should be subservient to the needs of the application. This is
not a universal claim because many database applications do require a
number of disparate applications and extensibility.

In such cases, it makes sense to have referential integrity constraints.
At the time I used it, RDM did not permit us to define referential
integrity within the DDL schema. I don't believe that the CODASYL
specified a grammer for such constraints however, theoretically, it should
be quite feasible. We did not require DDL enforced referential integrity;
our application provided it since it was the only user interface aside
from ad-hoc read & report queries.

I have seen many situations where the industry leader relational database
was used in situations where real-time performance was required. In those
situations the applications "owned" the data and business requirements to
support user access via ad-hoc SQL were specious. Nevertheless, in
marketing terms, using the industry leader carries considerable clout. I
don't usually waste my breath trying to suggest alternatives however, when
the performance and reliability of the application is entirely subservient
to the datastore, things tend to go FUBAR. I can tell you (privately)
about two incredibly huge projects that were compromised in this manner.
In the case of an advanced air traffic management system, they had to
invent their own internal data management system because they were
contractually required to use only the leading vendor RDBMS.

Surely it is time that the enlightened people begin to educate the rest of
us about such issues. There are too few evangelists of alternatives to the
enterprise RDBMS.

Steve Pushak
<http://home.infinet.net/teban/profile.htm>

Stephen_Pushak wrote:
Yes, direct links can be faster than the indexes most often used by SQL-DBMSs. However,
there are other considerations. Network links are often unidirectional and brittle (see
below). They also add another level of complexity -- two different ways to navigate to
data and only one can be used in certain circumstances (the user must have this
knowledge). Finally, adding an index is much easier that adding another link.

Relational query languages can map to non-relational systems, but emulating physical
links can be problematic. SQL is portable and well-known. Information on it is
universally available (see our SQL Tutorial: http://www.firstsql.com/tutor.htm) and a
large number of developers are familiar with it. Native APIs can be difficult to use,
are often incomplete and are not portable nor well known.

Simple assertions like "network links are brittle" are missing necessary details. That
shouldn't be a problem. There is plenty information about this available.

The difference with relational links (often indexes) is that they are purely for
performance and not required. A corrupted index can be easily rebuilt because no
information is lost --- the actual relational links are no more than common values in
tables. Most network design encourages removing 'redundant' columns so a broken link can
result in information loss that is irretrievable.

Network links are not information bearing. In fact, they can easily be created
incorrectly. The network data model in weak in design techniques. The relational model
produced normalization, a very powerful design capability.

The key here is "disparate applications and extensibility". Only a small number of
projects can guarantee they will *always* be a single application and will never be
extended. This requires a crystal ball. Better to be prudent and use a totally solid
data model.

Application enforcement of database constraints is widely seen as a bad idea. The
likelihood of incomplete coverage is very high, and verification of proper coverage is
very labor intensive and error prone. Failures in this area cause data corruption
diasters. In addition, relational introduced the idea of declarative constraints which
are even less error causing.

It is likely those failures were caused by bad design decisions (or contracts) not by
using an RDBMS. Using the major SQL-DBMSs for real-time applications can be a bad idea.
OTOH, there exist SQL-DBMSs that are implemented for this purpose.

In general, enterprise applications require "disparate applications and extensibility",
and RDBMSs fulfill that need far better than any alternative. They are also 'industrial
strength'.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

<..>
The key phrase being "In general". There are cases where the application
would benefit from using something besides an RDBMS.

We use an active object database (GemStone/S) for our application, which is
a next generation rewrite of a previous RDMBS application. The first
version is still in production and works fine. But, we find using an
active OODB has allowed us to add model complexity that was just too hard
to do with tables.

This point has come up many times before in this forum. And I think one
point of disagreement is due to a fundamental difference in our design
perspective: those that like an RDB think about storing data; I think about
storing objects.

In every system I've worked on that did object to relational decomposition,
the project overhead for doing that decomposition ended up taking 50% to
75% of the total project effort.

In our opinion, using an OODB (and Smalltalk) is a competitive advantage,
since most of our competitors are stuck with a relational database.
--
Bob Nemec
Northwater Objects