Hello to everyone...
I'm doing a university thesis and I need a "state of the art" of real time
solutions for databases (both commercial and, most of all, anything
opensource or wathever).
Thanks to everyone who will help with names, sites, references and so on..
Bye

Xfiler wrote:
What exactly are "real time solutions for databases"?

could have timestamps and validity periods and transactions could have
specified, among other features, an hard or soft deadline before which the
result have to be returned (otherwise a feilure takes place)...
This in two words... an example could be oracle TimesTen.
Bye

Op Wed, 08 Nov 2006 17:14:01 +0100 schreef Xfiler <xfiler (AT) fastwebnet (DOT) it>:
Here's one: Polyhedra from ENEA. <http://www.polyhedra.com>


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/

Xfiler wrote:
those sound like features of a temporal DB to me

now there's a real-time feature.

So you mean you are waiting for Oracle release 100?

But seriously, you have barely begun to describe what you would
consider a RT DBMS.

I have no products to offer you since almost every RT system I built
that needed a DB, had a custome DB built with it specifically for that
system. With the right resources, even oracle can meet realtime
demands.

Ed

"Ed Prochak" <edprochak (AT) gmail (DOT) com> ha scritto nel messaggio
news:1163099494.818281.85250 (AT) k70g2000cwa (DOT) googlegroups.com...

Custom DB built from zero or from a gpl / open source DBMS? Could you be
more specific? Because probably it is what I'll be asked to do...

tx...
Manu

Xfiler wrote:
It has been a while since I did any. There wasn't much open source
around yet. And most of the real time applications were fairly small.
(Think of a 20megabyte disc as BIG and you get an idea.)

One QC Database was pure custom. It was implemented as a set of
circular files (old data automically overwritten by new data so no
explicit DELETE operation was needed.) Each "table" was a separate
file.

Another used what's now an ancient OTS product: Borland Database
toolbox. That was a single user DB, so we had wrapper functions to deal
with concurrency issues. (they worked for most cases, but scaled
poorly.)

Another was custom, built around the premise that the queries were
known at DB build time (the DB was on CDROM). That one also had custom
data compression to get all the data onto the CD.

You are obviously looking for a larger type application. The last major
system I worked with ended up using ORACLE. The chief factor in the
choice was not the performance, but the reliability. This was for a
medical testing system. The criteria was: it was safer to loose an
entire test result than to store erroneous or partial results. Other DB
products that allowed dirty reads, or did not have reliable
commit/rollback operations did not make final consideration. (I did the
DB selection for that and one of my favorites failed the reliability
testing)

Sorry that some of this is ancient history. I migrated out of the
embedded/realtime area and work mainly in odrinary databases nowadays.

some generic advice:
One factor that makes the most sense in selecting a DB (or anything in
a RT system) is deterministic response time. Rather than being able to
dynamically set deadlines, hard or soft, a RT system can be designed
around a database product IFf it can provide repeatable, predictable
response times. Look at the available products in that sense and you
may be able to widen your search beyond DBMS products that label
themselves Realtime.

Also, if yours is an embedded system, then administrative issues may be
a selection factor. A DB thats needs certain operations to be done
manually on a regular basis would not fit am embedded system well.

I hope all this helps.
Ed

I say, all this did help a lot, thank you very much for the time spent
writting.
Manu