Warum ist Interbase besser als Paradox ???

[danielA]

Hallo @all,

Ich stehe Momentan vor einem riesigen Problem.
Ich muß eine Erklärung finden, warum Interbase besser und vor allem sicherer ist als Paradox.
Das hört sich wahrscheinlich dumm an, die Frage ist meines erachtens aber nicht so trivial.
Ich weiß, Interbase arbeitet nach dem Client/Server Prinzipund Mengenorientiert, was die Frage eigentlich für mich schon beantwortet (sicherer da nur eine Anwendung auf die Tabellen zugreift nämlich der Server). Das reicht aber noch nicht. Ich habe Fragen zu beantworten wie:

Zitat:

Was ist wenn eine Tabelle mal crashed ?
Wie reorganisiere ich eine solche DB ?
Wie oft crashed Interbase ...
Jaa keine FOREIGN_KEYs und AUTO_INCREMENT Felder die DB ist sonst gleich im A... !

Also bei mir ist Interbase noch nie gecrashed, somit kann ich darauf keine Antwort geben.
Im Internet habe ich sonst auch nichts dazu gefunden (scheint ein gutes Zeichen zu sein).
Bitte helft mir, ich weiß echt nicht wie ich hier noch argumentieren soll.

Vielen dank im voraus

danielA

[sakura]

Wenn ich mich recht entsinne, dann sind Paradox Tabellen auf 65Kb Größen limitiert. (?) Ist auf jeden ein gutes Argument.

IB ist allemale performanter.

IB ermöglicht durch sein C/S Prinzip die Nutzung durch mehrere Nutzer. Paradox gibt in einem solchen Fall keine Garantien.

IB läßt sich als eine einfach Datei leichter sichern, falls es doch mal crashen sollte.

IB unterstützt den SQL Standard besser.

IB bietet "Stored Procs" und vernünftige Batchabläufe.

Das wäre mal ein kleiner Anfang.

[danielA]

Danke für die schnelle Antwort.

Die Datenstruktur von Paradoxtabellen kann, soweit ich weiß, nur 65 Kb groß sein die Tabelle aber kann bis zu 2 GB groß werden (theoretisch).

Performance und zusätzliche Funktionalität ist leider sekundär, ich muß ihm die Sicherheit klarmachen.

Mehrere Nutzer sind auch mit Paradox möglich *unter den Tisch verkriech*

Mit der Sicherung sehe ich ähnlich, er nicht.

Mein Problem ist, ich muß jemanden überzeugen, der in den letzten Jahren durch dick und dünn mit dbase und Paradox gegangen ist.
Daraus schließen sich verständlicherweise diese Fragen und Aussagen, die ich oben aufgeführt habe. Nun soll aber Interbase eingesetzt werden, was auch eine vernünftige Datenbankstruktur ermöglicht und meines erachtens auch erfordert. Nur bevor ich diese Skepsis nicht ausgemertzt habe, komme ich leider kein Stück weiter. Ich hoffte, das durch eine Diskusion zu bereinigen die Fragen wurden aber leider eher mehr und Elementarer als das ich sie beseitigen konnte.


Gruß danielA

[MrSpock]

Hallo DanielA,

ich gehöre auch zu denen, die wie derjenige, den du überzeugen musst, gute Erfahrungen mit Paradox gemacht hat. Wir haben recht große Anwendungen geschrieben, die auf Paradox im Netz (Gleichzeitiger Zugriff bis max 10 user) basieren und seit Jahren problemlos laufen. Probleme, die andere hatten (Indexcrash) kamen nur sehr selten vor und konnten ausnahmslos ohne Datenverlust wieder korrigiert werden.

Zwei Argumente die dir helfen könnten, wären:

1. Anzahl der User (wenn die Anzahl größer als 10 wird, ist die Performance von Paradox schlecht.)
2. Das Sicherheitskonzept: Paradoxtabellen können nur über Kennwörter geschützt werden. Weitere Sicherheitskonzepte unterstützt Paradox nicht.

[sakura]

Ein guter Grund für IB sind ROLLBACKS, egal hier ein paar URLs, die Dir vielleicht weiterhelfen

http://www.masternet.com.co/docs/intervspara.pdf
http://www.orbital.co.za/text/ibreasons.htm
http://www.borland.com/interbase/pdf/ib65_feamatrix.pdf
http://www.ibphoenix.com/ibp_sqlintdata.html
http://community.borland.com/article...,27006,00.html
http://www.ibphoenix.com/ibp_tip_perf.html

www.google.com

[danielA]

Danke erstmal für die Antworten,

ich wollte hier auch nicht aussagen, daß Paradox schlecht ist, im Gegenteil aber seine Zeit ist denke ich mittlerweile vorbei.
Wir werden jetzt auf jeden Fall mit Interbase arbeiten und die Überzeugung kommt, denke ich, mit der Zeit von selbst.
Ich werde meine Datenbankstruktur auf jeden Fall so entwickeln wie ich es einmal gelernt habe.

@MrSpock

Deine Aussagen kann ich nur bestätigen und Reorganisieren mußten wir auch fast nie (bisher auch immer ohne Datenverlust das war bei DBase noch etwas anderes).

@sakura

Deine Links sind echt gut da sind einige Sachen dabei die ich gut für meine Argumentation und weitere Arbeit mit Interbase gebrauchen kann.

Was mich aber noch interessieren würde, hat von euch schonmal jemand schlechte Erfahrungen mit Interbase gemacht, in bezug auf Datenverlust etc. ?

Gruß danielA

[Alfons_G]

Es gibt bei Interbase ein Problem in der Zusammenarbeit mit MS SQL-Server, für das aber Borland einen Workaround bereitgestellt hat:
Wenn der IB-Server auf einem Rechner installiert wird, auf dem ein MS-SQL-Server läuft, werden Dateien des MS-SQL-Servers überschrieben. Diesen Schaden kann man nur durch Neuinstallation von MS SQL beheben
Bei einem Kundenserver kann das zu einem grösseren Problem werden. Bei Borland gibt es ein Dokument, das beschreibt, welche MS-Dateien man vorher sichern muß, um sich die Neuinstallation zu ersparen.

[danielA]

Hallo Alfons_G,

danke für den Hinweis, der wird mir sicherlich in naher Zukunft noch nützlich sein. Auf solche Sachen kommt man ja sonst leider erst wenn es zu spät ist (und dann am besten noch beim Kunden).

Na, so wie es hier aussieht, scheint Interbase doch recht sicher zu sein .

Gruß danielA

[Lemmy]

Hi,

was vielleicht zieht ist, dass die BDE nicht mehr weiterentwickelt wird, und somit keine Zertifizierung seitens Microsoft mehr stattfindet, so dass es passieren kann, dass bei kommenden Windows die BDE nicht mehr zu installieren ist, was die Nutzung von Paradox schon ziemlich einschränkt. Zudem wird Borland diese Technologie (also auch Komponenten) nicht weiterentwicklen, so dass über kurz oder lang auch sonstige Probleme beim Programmieren auftreten können.

Was Interbase / Firebird auszeichnet sind meiner Meinung nach folgende Punkte:

* Transaktionen: bei IB/FB laufen alle Aktionen in Transaktionen. Wird eine Transaktion zurückgenommen werden alle durchgeführten Änderungen verworfen. Das wird vorallem bei großen Datenbankanwendungen interessant.
* Multi-Generationen-Architektur: Durch die MGA ist es sichergestellt, dass bei großen Auswertungen (die lange laufen) die Datenbank auch weiterhin einen vollen Zugriff auf die Daten bieten kann. Wird also eine Transaktion gestartet sieht diese die Änderungen aller nachfolgenden Transaktionen nicht, außer die Transaktion wird geschlossen und eine neue Transaktion wird geöffnet.
* Fat-Server-Architektur: Durch Triggers und StoredProcedures ist es möglich, viele Aufgaben direkt auf dem Server durchzuführen, ohne dass Daten zum Client transportiert werden müssen. Das bringt nicht nur Geschwindigkeit sonder hat auch den Vorteil, dass bei Änderungen an diesen Vorgängen lediglich die DB mittels SQL-Statements verändert werden muss, ohne Änderungen an den Clients (speziell bei Fehlern).

Dann kommt natürlich noch (zumindest für mich) der Vorteil von OpenSourve dazu, für die, die das als Nachteil werten, steht ja auch IB6.5 bzw. bald IB 7 zur Verfügung.

Grüße
Lemmy

[Hansa]

durch Zufall gefunden:

http://www.interbase2000.de/IBAbout/features.htm

Lohnt sich zu lesen. Das andere was noch dort steht auch!

Gruß
Hansa