Was is eigentlich so toll an DBISAM?

[alzaimar]

In einem Projekt wird DBISAM eingesetzt, und zwar die Server-Version. Alle schwören auf das Teil, und ich frage mich, wieso? Wieso nimmt man nicht eine Firebird o.ä. und hat Ruhe im Stall?

Oder hat DBISAM irgendwelche Features, die man bei anderen DB vergeblich sucht?

Kann mich jemand aufklären?

Danke.

[TBx]

Ich weiß nicht, was so toll daran sein soll, aber ich habe auf der Homepage des Hersetller folgendes gefunden:

Zitat:

Features Not Supported

Fail-safe transactions and referential integrity are not currently supported in DBISAM.

Das finde ich dann doch eher abschreckend.

Gruß

onlinekater

[Bernhard Geyer]

Weil DBISAM so toll ist hat ja der Hersteller mit ElevateDB 'ne neue Desktop-DB entwickelt.

[alzaimar]

Genau diese Antworten habe ich erwartet.

Tja, eine große deutsche Firma (die größte in ihrem Segment) wickelt ihre interne Auftragsbearbeitung im Mehrbenutzerbetrieb über DBISAM ab. Nun sollen wir dort Einiges weiterentwickeln... Die Frage, die sich nun stellt, ist die: Wollen wir überhaupt? Denn der Oberprogrammierer von denen kennt nur DBISAM und will nur DBISAM ('Och, wir haben uns inzwischen daran gewöhnt').

Ich denk mal, das wir den Auftrag nur übernehmen werden, wenn die sich von DBISAM verabschieden. PostGresSQL oder FB wirds dann wohl werden.

[Bernhard Geyer]

Wenn ihr weiterentwickeln woll heißt das das ihr alles umschmeißen werdet oder auf bestehenden Code weiterentwickelt? Die "Entfernung" einer ungeliebten DB würde ich in mehreren Schritten durchziehen:

1, Konzentration des DB-Zugriffs auf eine Unit
2, Einbau des Bridge-Pattern
3, Implementierung des Zugriffs auf alternative DB
4, Konverter (Export/Import?) erstellen + Durchführen
5, Umstellen auf neue DB oder Programm so lassen das mehrer DB's unterstützt werden.

[QuickAndDirty]

Ähm,
die Features sind im wesentlichen Stabiltät!!!!(das ding hat bei uns noch nie Daten oder Indices verloren), Geschwindigkeit(ähnlich wie Paradox) und es ist ein BDE Replacement(Wenn man Umstellt doch recht wichtig).
Du brauchst es nicht installieren einfach Datein kopieren fertig.
Für die Server Version muste noch den Server starten.
Vor allem ist es eine Datei basierte Datenbank. Sprich es gibt Ranges. Dadurch das man auch einen Server einsetzen kann hat man dennoch nicht das Problem mit dem Windows-Locking (OpLocks, blöde UDP-Kommunikation in schlechten Netzen).
Und es gibt viele Softwarehäuser die DBisam einsetzen.

[Bernhard Geyer]

Evtl. hilft ja die Feature-Matrix ElevateDB <-> DBIsam.

[alzaimar]

Hi Bernhard: Die verwenden eh nur datensensitive Steuerelemente, insofern wäre ein Search/Replace 'TDBISAMTable'=> 'TADOTable' die vermutlich richtige Vorgehensweise im 2.Schritt.

Ich würde das eh so machen, das man die neue App parallel entwickelt und durchtestet, und dann die alte DB konvertiert und -bupps- loslegt.

Dessenungeachtet ist es jedoch imho besser, eine Feinspezifikation auf Grundlage der vorhandenen Applikation zu erstellen, und das dann als Grundlage für eine komplette Reimplementierung ohne DSS zu verwenden. Die Applikation ist relativ ja übersichtlich. Es kann auch sein, das schon eine objektorientierte Herangehensweise ein Overkill ist. Wir sprechen von vielleicht 20 Tabellen (Kunde, Auftrag, Auftragsdetails, Auftragsdaten, Lookuptabellen). Man muss nur ein Reconcile einbauen, das ist das 'Komplexe' an der Sache.

Zitat:

Zitat von QuickAndDirty

...Stabiltät!!!!(das ding hat bei uns noch nie Daten oder Indices verloren)

1x täglich läuft der Admin durch die Bude und brüllt 'Alle mal die SW beenden'... Weil eben mal wieder irgendwas nicht stimmt. Mehrbenutzerbetrieb mit Desktop-DB eben.

Zitat:

Zitat von QuickAndDirty

Geschwindigkeit(ähnlich wie Paradox)

Auch das kann ich nicht bestätigen: Die Applikation kopiert die gesamte DB aus Performancegründen als 'InMemory' oder wie das heißt. Das dauert erstmal beim Start eine Minute. Filtern ist auch lahm (OnFilterRecord)... Ich denke mal, das geht mit FB/PostGres schneller.

Zitat:

Zitat von QuickAndDirty

Du brauchst es nicht installieren einfach Datein kopieren fertig.

Bei einer in-House-Lösung ist das egal. Und nebenbei: ADO muss man auch nicht installieren...

Zitat:

Zitat von QuickAndDirty

Vor allem ist es eine Datei basierte Datenbank. Sprich es gibt Ranges.
Dadurch das man auch einen Server einsetzen kann hat man dennoch nicht das Problem mit dem Windows-Locking (OpLocks, blöde UDP-Kommunikation in schlechten Netzen).

Das verstehe ich nicht. Kannst Du mir das erläutern?

Zitat:

Zitat von QuickAndDirty

Und es gibt viele Softwarehäuser die DBisam einsetzen.

Das erinnert mich an den Spruch 'Fresst Sch**** 100.000.000 Fliegen können nicht irren'.

Die Coder, die von DBISAM schwärmen, finden die Features wie 'Locate', 'Post' und die total super einfache Programmierung mit den TDBEdits toll, und wundern sich, wenn man denen erzählt, das das mit JEDEM TDataset funktioniert.... Hmmm... Das deutet auf ein bestimmtes Niveau in 'vielen Softwärehäusern, die DBISAM einsetzen' hin.

So wie ich das sehe, ist DBISAM eine coole Desktop-DB, aber mehr eben auch nicht.

Danke an alle Mitfühlenden für die Denkanstöße und Hilfe.

[RavenIV]

So, nun meine Meinung dazu.

DBISAM ist ein Relikt aus den Anfängen der Programmierung.
Ähnlich wie Sybase, Oracle, Paradox. Im gleichen Atemzug will ich mal BDE nennen.
Damals wurden nicht megabyteweise Daten hin-und-her geschaufelt und eine DB ist nicht so schnell gewachsen. Ausserdem waren die Anforderungen an die DB nicht so hoch.

Heutzutage sieht das ganze ein Wenig anderst aus.
Es wäre allmählich an der Zeit, solche "Oldies" gegen neue Technologien auszutauschen.
Als "neu" würde ich MySQL, PostgreSQL oder (meinetwegen) auch FireBird bezeichnen.
Dazu noch anständige Komponenten für den DB-Zugriff und die Sache ist geritzt.

Mein persönlicher Tip:
Verzichte auf den Firebird und lass die Finger von den IBObjects.
Alles viel zu kompliziert und zu unpraktisch für den Entwickler.
Nimm lieber MySQL und die ZEOS-Komponenten, damit wirst Du Freude haben.

Wie schon erwähnt, ist dies alles meine persönliche Meinung und Erfahrung. Sie muss (und wird) sich nicht mit der Meinung anderer Leute hier im Forum decken.

[mkinzler]

Zitat:

Ähnlich wie Sybase, Oracle, Paradox.

Also Oracle und Sybase sind zwar alt würde ich aber keinesfalls mit DBISAM oder Paradox gleichsetzen wollen.Oracle ist immer noch die fortschrittlichste Datenbank, die in vielen dingen Vorreiter war/ist und das DBMS, welches am nähsten am Standard ist (weil der Standard viele Features von Oracle übernimmt und Oracle die Standardkonformität als Leitsatz verwendet; anders als andere Hersteller).
Ich würde auch alt oder neu nicht als Entscheidungskriterium für oder gegen eine DBMS wählen. Zudem ist der Kern von Interbase/FireBird auch schon sehr alt und der MSSQL hat den gleichen Vorgänger wie die aktuellen Sybase-Versionen, also bleibe nach deiner aussage also nur MySQL und PostGres übrig.
Ich würde aber klar von MySQL abraten, da alzaimar ja klar auf OS-DBMS zu setzen scheint. Ich würde persönlich FB wählen.

[PaulJr]

Hallo Programmierer! :???:

In der Praxis ist es allerdings so:

Man entwickelt ein Programm der mit einer Datenbank arbeitet und möchte es verkaufen.

Wie geht das also?

Viele Firmen (Käufer) benutzen schon Datenbanken (wie z.B. MySQL, MS-SQL, Oracle und andere)
und logischer Weise in vielen Firmen die allwissender Datenbank-Administratoren weigern sich
mit aller Kraft vor jeglicher Änderungen (damit meine ich: hat er z.B. Oracle, dann sind andere Datenbanken TABU etc…).

Willst Du also dein Produkt verkaufen musst Du flexibel sein und viele Plattformen bedienen können.

Also: Welche Zugriffs-Komponenten würdet Ihr dann empfehlen?

Im übrigem: Immer wieder höre ich hier mehr oder weniger: das ist alt bzw. veraltet, dies ist neu usw…

Also wirklich, ich zweifle nicht daran, dass hier sehr gute Programmierer zu Wort kommen,
aber manchmal drängt sich bei mir der Verdacht, dass hier eher Theoretiker und kaum Praktiker
zur Wort kommen, da in der Praxis sieht der Programmieralltag anders aus…

Viele Grüße

PaulJr

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Oracle ist immer noch die fortschrittlichste Datenbank, die in vielen dingen Vorreiter war/ist und das DBMS, welches am nähsten am Standard ist (weil der Standard viele Features von Oracle übernimmt und Oracle die Standardkonformität als Leitsatz verwendet; anders als andere Hersteller).

Oracle: Vorreiter und Standards? Wenn ich bedenke wie oft wir uns über Oracle ärgern. Da ist der MS SQL-Server und MySQL eigentlich schon Kinderleicht zu verwenden auch wenn die auch ihre Macken haben.

Zitat:

Zitat von mkinzler

Ich würde auch alt oder neu nicht als Entscheidungskriterium für oder gegen eine DBMS wählen.

Sehe ich genauso.

Zitat:

Zitat von mkinzler

.. und der MSSQL hat den gleichen Vorgänger wie die aktuellen Sybase-Versionen,

MS SQL wurde aber mit der 7er-Version komplett renoviert. Ob da noch soviel von Sybase-Code übrig geblieben ist.

Zitat:

Zitat von mkinzler

Ich würde aber klar von MySQL abraten

Gründe? Einige der "alten" Mängel wurden in aktuellen Versionen behoben.

[mkinzler]

Zitat:

Gründe? Einige der "alten" Mängel wurden in aktuellen Versionen behoben.

Es fehlen aber immer noch Features. Ich habe aber eher an das Lizenzierungsproblem gedacht.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Ich habe aber eher an das Lizenzierungsproblem gedacht.

Wenn man für sowas zentrales Element wie eine Datenbank nie und niemals nichts zahlen will, ok. Wir haben Kunden die sich für das gesparte Geld einer Oracle-Installation einen "fetten" Server mit lizenzierter MySQL-Datenbank mit Hotline+Supportvertrag bei MySQL geleistet haben. Denen war klar das die Daten die sie hier vorhalten viel Wertvoller sind als hier auf den letzten € zu schauen.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Oracle: Vorreiter und Standards? Wenn ich bedenke wie oft wir uns über Oracle ärgern. Da ist der MS SQL-Server und MySQL eigentlich schon Kinderleicht zu verwenden auch wenn die auch ihre Macken haben.

MySQL ist komplett inkompatibel mit allem was sich DBMS nennt, das zusammen mit "Standards" in einem Satz zu nennen ohne wild zu fluchen ist eher ungewöhnlich.
Ora ist ein uraltes DBMS ja, und es muss auch nicht einfach zu bedienen sein. Wer Ora einsetzt hat auch jemanden, der es ab & zu mal streichelt...
Ich selbst habe zu viel, zu lange mit Ora zu tun um es nicht zu hassen. Aber wirklich schlecht ist es nicht, ich hasse jedes DBMS... :mrgreen:

Oben wurde auch Sybase erwähnt. Das ist das originale DBMS von MSSQL (MS hat die Engine nicht selbst entwickelt), und im Gegensatz zu MSSQLs grauenvoller DB-engine, wurde das seit damals auch weiterentwickelt...

Zitat:

Zitat:

Zitat von mkinzler

.. und der MSSQL hat den gleichen Vorgänger wie die aktuellen Sybase-Versionen,

MS SQL wurde aber mit der 7er-Version komplett renoviert. Ob da noch soviel von Sybase-Code übrig geblieben ist.

Jupp, es dauerte bis MSSQL2005 bevor dieses Viech überhaupt versionierte, konsistente Zugriffe ermöglichte. Vorher haben Selects entweder alle blockiert oder waren dirty. wtf?

[Bernhard Geyer]

Zitat:

Zitat von Elvis

MySQL ist komplett inkompatibel mit allem was sich DBMS nennt, das zusammen mit "Standards" in einem Satz zu nennen ohne wild zu fluchen ist eher ungewöhnlich.

Wer weis wenn mehr Kunden es einsetzen kommt das fluchen ja noch ...

Zitat:

Zitat von Elvis

Ora ist ein uraltes DBMS ja, und es muss auch nicht einfach zu bedienen sein.

Und wieso nicht? Wieso muß man Dinge die unter vielen anderen DB's verständlich sind oder über eine einfache GUI zu bedienen sind so kompliziert machen? Ok - wer Oracle-Admin ist hat einen Rentenjob solange die Firma Oracle nicht rausschmeißt.

Zitat:

Zitat von Elvis

Jupp, es dauerte bis MSSQL2005 bevor dieses Viech überhaupt versionierte, konsistente Zugriffe ermöglichte. Vorher haben Selects entweder alle blockiert oder waren dirty. wtf?

Alles blockiert auch wieder nicht, solange man die PK's richtig anlegt dann sind es "nur" Pages die gesperrt werden.

[Elvis]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Elvis

Ora ist ein uraltes DBMS ja, und es muss auch nicht einfach zu bedienen sein.

Und wieso nicht? Wieso muß man Dinge die unter vielen anderen DB's verständlich sind oder über eine einfache GUI zu bedienen sind so kompliziert machen? Ok - wer Oracle-Admin ist hat einen Rentenjob solange die Firma Oracle nicht rausschmeißt.

Ist schon richtig. Aber wer einen Datenbestand hat, der Ora sinnvoll macht, der braucht IMHO sowieso einen DBA.
OTOH, vieles in Ora scheint so gemacht zu sein, um für den DBA eine Jobversicherung zusein, wodurch der wiederum weiterhin Ora empfiehlt, und.... *Kopf explodiert*

Das war aber nicht die originale Frage. Die originale Frage war, warum man sich ein kommerzielles DBMS antun soll, dass in der Konstellation keinerlei Vorteile gegenüber ernsthaften freien DBMS bringt. (Firebird/pgSQL)

Falls die Daten in DBISAM zu halten waren, dann wäre Firebird eine exzellente alternative.
Ich selbst entscheide mich auch immer öfter dafür, wenn es die Umstände zulassen.
Gerade die Möglichkeit Prototyp-Appserver mit embedded FB und der DB auf eine Mono/Linux zu kopieren und färtsch.
Jo, das hat was. :-)