kommerzielles Datenbanksystem gesucht

[hanspeter]

Zitat:

Sortierungen erledige ich fast immer im DAL. Die meisten RDBMS generieren bei Sortierungen wesentlich ineffizientere Ablaufpläne und man erhöht nur unnötig die CPU-Last auf der DB-Maschine.

So mache ich es zur Zeit ja auch.
Das Problem ist das das Update in die Datenbank teilweise zu lange dauert, da ich immer das Ergebnis des gesamten Feldes zurück schreiben muss.
Bei einer WLan Verbindung hat die Parabolantenne vom Fernsehen mal gerade alles zugestopft. Oder ich greife über ein
Tunnelprotokoll und ISDN Router auf den Server zu. Es liegen manchmal bis zu 2 km temporär installiertes Netzwerk zwischen den Punkten.
Vor Ort muss ich immer sofort sortieren, da das Ergebnis sofort auf die Großanzeigen und den Schriftgenerator des Fernsehens geht und praktisch zeitgleich dargestellt werden muß.
Danach übertrage ich die neue Rangierung auf den Server.
Da kann es bis 10 bis 30 sec dauern, ehe ein Ergebnis inklusive Kontrollen verarbeitet ist.
Ich bin jetzt dabei ein Protokoll mit lokaler Serverspiegelung aufzubauen.
Damit läuft die Datenerfassung vor Ort schnell und sicher.
Ein Tool soll im Hintergrund die Replikation (lese Ergebnisse aus Datenbank A und übertrage diese in die Serverdatenbank) unabhängig durchführen.
Meine Überlegung ist nun, nur das eine Ergebnis zu übertragen und die Sortierung auf der Serverseite nochmals vorzunehmen.
Vom Server wird das laufende Ergebnis dann zur Presse,Internet und Anzeigen weitergeleitet.
Nebenbei bemerkt gibt es eine Vielzahl von unterschiedlichsten Sortierungen und wenn den Funktionären was neues einfällt...

Ich meine das ist insofern nicht OT, da das alles mit Firebird realisiert ist und Firebird nicht einmal in die Nähe seiner Grenzen gelangt und ich von der Stabilität und Geschwindigkeit des Firebird Servers immer noch begeistert bin.

Mit anderen Datenbanken hatte ich bei unsicheren Netzverbindungen wesentlich größere Probleme.
MySQL hatte ich probiert. Damals gab es jedoch Probleme mit den (damals) nicht vorhandenen Transactionen.
Ein File gestütztes System (vor Urzeiten Paradox und dann MS Access) waren schlichtweg nicht geeignet und jeder Aussetzer im
Netzwerk eine Katastrophe.
Aus Urzeiten des Interbaseservers gibt es ja noch die Anektote das dieser im Leitsystem eines amerikanischen Panzers eingebaut ist. Beim Abfeuern der Kanone setzt immer das Bordnetz aus und dieser Server ist komplett selbstständig restartfähig.

Gruß Peter

[IBExpert]

Zitat:

hab mal die Benchmarkergebnisse nur überflogen, aber kann es sein, dass hier nicht gesagt wird über welche Daten man den Index (soweit möglich) erstellt hat? Also ganz ehrlich, man kann jede DB in ihrer Paradedisziplin mit anderen Vergleichen (da schlägt soweit ich das in Erinnerung habe MySQL auch Oracle um einiges).

auf der Single User Ergebnisseite schlägt MySQL ja auch Firebird manchmal, geht ja genau so aus dem Test hervor, wie viele andere Erfahrungsbericht das verdeutlichen. Die meisten Webserveranwendungen arbeiten ähnlich wie eine Singleuser Anwendung, wenn auch mit mehreren Threads, aber nutzen oft identisch Daten mit vergleichsweise einfachen SQLs. Für Webserver ist MySQL bekanntermaßen eine bewährte und schnelle Plattform.

Zitat:

Es ist jedoch ohne jegliche Aussage. Ein wenig ummodelieren der Anfrage und gutes Design der Datenbank lässt die Sache schnell mal anders aussehen. Da denke ich sollte man mit Benchmarks vorsichtig sein.

klar sollte man mit Benchmarks vorsichtig sein, aber einen Hinweis geben die eben schon. Am Datenmodell mit den paar Tabellen kann ich so nichts finden, was problematisch ist. Die Datenmengen sind auch angegeben. Jede Datenbank hat seine Vor- und Nachteile, die eine kommt mit komplexen SQL Statements sehr gut klar, die andere kann man durch bestimmte SQLs besonders ärgern (Bei firebird zum Beispiel sortieren großer Datenmengen nach mehr als einer Spalte ohne genau passenden Index oder select count ohne where).

Zitat:

* Wie lange wird es Firebird (oder Andere) geben? (Oracle gibt's schon ein Weilchen)

Interbase ist als Vorläufer von Firebird im Jahr 1983 entstanden (gegründet von Jim Starkey,
der damals schon ca 10 Jahre, also seit 1973) als für DEC gearbeitet und war für deren Datenbank RDB verantwortlich)

Larry Ellison hat die Firma Oracle 1977 gegründet, aber auf jeden Fall deutlich besseres Marketing gemacht für sein zugegeben gutes Produkt.

Zitat:

* Wie wichtig ist dem Kunden ein großer Name (es sind Kunden!)

Sehr unterschiedlich, Kunden wie dpa Deutsche Presseagentur setzen bei ihrem Redaktionssystem voll auf Firebird. SAS.COM mit mehreren Millarden $ Umsatz für Software und Services setzt ebenfalls voll auf Firebird und lässt sich sogar eine eigene Version (Vulcan) programmieren. Der Chef von SAS hatte dafür auch mal in einem Interview sehr gute Argumente genannt und unter anderem seine Erfahrungen mit Oracle geschildert. Viele nutzen schon andere Datenbanken ohne es zu wissen, wir kennen da einige Anwendungen unserer Kunden. Man wundert sich so manches mal wo firebird schon alles eingesetzt wird.
Die Argumentation gegen Open Source war auch manchmal sehr seltsam, so mussten wir ein sehr großes deutsches Telekom-munikationsunternehmen erst überzeugen das die komplette Umstellung eines Rechenzentrums von Windows auf Linux ja auch auf Open Source basiert. Die ursprüngliche Aussage uns gegenüber "Wir dürfen keine Open Source Software einsetzen" war damit immerhin widerlegt.

Zitat:

* Wie häufig findet man gute Firebird-DB-Designer? (gibt es da eigentlich Zertifizierte oder so?)

Ein Zertifikat macht noch keinen guten DB Designer, es zeigt nur das er einen Kurs besucht hat. Gerade bei den Kursen der großen Anbieter habe ich schon einige Absolventen kennengelernt, die sich durch Ihren Abschluss für ziemlich allwissend hielten, aber ganz banale systemübergreifende Indexprobleme nicht lösen konnten. Ein guter Designer kann im Prinzip alle relevanten Datenbanksysteme nach kurzer Einarbeitung sinnvoll nutzen, ein schlechter macht das so wie er das schon immer gemacht hat. Das Problem ist natürlich bei Firebird ein wenig anders, denn die Installation ist gerade mal 4MB groß, es gibt nur wenige Kommandozeilentools und die meisten SQL Befehle sind auch Standard. Was man sonst noch so wissen sollen kann man bei uns lernen, wir bieten regelmäßig Workshops an. Wer selbst weiterlernen will kann dazu auch mit unserem Tool IBExpertLive Videos der letzten Firebird Konferenzen und teilweise Mitschnitte aus Schulungen kostenlso onine ansehen und hören.

Zitat:

Wenn du einen Kunden hast, der sich recht wenig für den Aufbau und die Optimierung einer DB interessiert, dann sind Namen wie IBM und Oracle schon etwas wert (natürlich auch wenn er Ahnung hat!). Wenn so ein Kunde schon einen Datenbankenspezialisten hat, dann ist der häufig teuer und gut darin ein bestimmtest DBMS zu verwenden. Natürlich kann der auch mit anderen umgehen (sollte er zumindest), aber wenn du hier Fortbildungen bei Oracle bezahlst...

Das Problem bei Oracle ist ja auch das du für den sinnvollen Betrieb auch wirklich einen Admin im Hause brauchst (plus einen weiteren als Urlaubsvertretung und einen weiteren, wenn der Vertreter im Urlaub auch mal ausfällt). Wenn ich mir überleg an wie vielen Schrauben man bei Oracle rumdrehen kann und wie viele Oracle Admins dann auch alles ausnutzen, dann finde ich das nicht immer sinnvoll. banale Beispiele: Bei der dpa brauchten wir Oracle Daten für den Import von Adressen. portionsweise ging es, aber 50000 Adressen auf einmal sprengten die Tempspace Einstellungen des Servers (nach diversen minuten war ein banales select via odbc treiber gescheitert, ohne order by, where oder sonstiges, einfach nur select * from tabelle. Fehlermeldung kam von oracle wegen user tempspace. der Admin war an dem Tag nicht da, kein anderer konnte helfen, also drumherum programmieren und portionsweise abholen. gleiches Problem bei einer Stadtverwaltung im Ruhrgebiet, Importieren der Strassentabelle war nicht möglich, immer nur buchstabenweise. Ich kenn noch viele weitere Beispiele wo mir Oracle viel Zeit gekostet hat. Auch DB2 hat aber schon einiges an Zeit gekostet.

Natürlich kann man auch oracle etc so konfigurieren, das das relativ wartungsfrei läuft, aber warum macht das dann keiner? Warum kann man das nicht out of a box installieren und muss nichts dran rumschrauben, damit es wartungsfrei läuft. Bei Firebird kommt es nur dann zu Problemen wenn die Festplatte voll ist oder der Programmierer typische Programmierfehler gemacht hat, aber das Problem hat wohl jede Datenbank. und aufgrund interner Kompression ist eine Firebird DB meist eh kleiner als die Datenbanken anderen Hersteller bei gleichem Nettodatenbestand. Solange das Betriebssystem noch Platz auf einem Datenträger frei hat, braucht man nicht eingreifen (mal von ganz seltenen Dinge wie das Erreich von 1,3 Mrd Transaktion, bei dem ein Backup/Restore zwingend erforderlich wird).

Gruß
Holger

[IBExpert]

Zitat:

OK. Es sind schon mal einige Fragen beantwortet. Die Hauptfrage was die Performanceprobleme verursacht (die Einstellungen der DB bezüglich Caching, ...) ist aber damit nicht beantwortet. Wichtig wäre zu wissen wie viel Speicher sich die Datenbanken genehmigen dürfen. Bei MySQL gibt es installationen die sind sehr sparsam so das bei großen Datenbanken permanent Dateizugriffe erfolgen müssen weil nicht mal die Indize ins Ram geladen werden können.

das unterscheidet sich wenig von Firebird, da kann man beginnen bei ca. 75 kbyte Datenbankcache (75 cache buffers zu je 1024 byte Pagesize) für alle User gemeinsam (firebird selbst nutzt ca 4-8MB) und das endet bei ca 1 GB Cache, beim Classicserver auch pro User. da ist dann nur noch die Frage wieviele Riegel man in den Server reinstopfen kann.

Ohne das genauer zu beleuchten kann man immer noch an diversen Schrauben drehen, es gibt auch bei firebird nicht nur cache buffers, sondern auch sort memory, sort block size etc. Es geht auch nicht immer darum ob dies oder das die beste Plattform ist, sondern ob man mit dem eigenen Businessmodell und den eigenen Programmierwerkzeugen und Kenntnissen etwas konkurrenzfähiges auf die Beine stellen kann.

Aus meiner Sicht ist eine plattformübergreifende Implementation aber immer schwieriger, insbesondere wenn es um große Datenmengen geht. Wenn man weiss das externe Appserver zum Beispiel ca maximal 2000 bis 3000 Datensätze pro Sekunde verarbeiten können, intern jedoch in Stored Procedures auf gleicher Hardware durchaus Werte von 50000 möglich sind (zumindest bei Firebird), spricht schon so manches dafür, sich auf wenige plattformen festzulegen. Plattformübergreifend kann man nur das nutzen was alle können. Das ist immer ein Kompromiss und der geht fast immer zu Lasten der Performance.

Gruß

Holger

[Elvis]

Hi Holger,

in Versionen <10 waren die Defaults schon fast absichtlich so getrimmt, dass sie ein admin ändern musste.
Nicht unbedingt total dämlich, da selbst ein 10G mit "smart defaults" nichtmal 20% der Leistung haben *kann*, die ein vernünftiges Setup haben kann.
Wer mehrere Tausend Euronen für ene RDMS Lizenz ausgibt wird sicherlich auch noch etwas in der Portokasse haben um sich ein schniekes NAS zuzulegen, um dort Tablespaces so auf unterschiedlichere Arrays zu verteilen, dass die Datenbank einzelne Phasen oder Teilmengen eines Statements parrallel ausführen kann.
(mehrere Prozis/Server wollen ja genutzt werden und die Suche im Index soll ja das Ausgeben der selektierten Daten nicht bremsen, right? )
Eine Ora DB die ihre Temp spaces überstopft ist entweder komplett dämlich aufgesetzt oder die Daten wurden "unschlau" eingefügt.
Oracle kennt nunmal DiretPathLoading, welches an der SQL Engine vorbei operieren kann um sehr große Datenmengen in einem Bruchteil der Zeit reinzuschieben.

Ich bin immer noch der Meinung, dass Ora momentan die Krönung der Schöpfung im RDMS Segment ist. Aber neben den Anschaffungskosten darf man die nötige Hardwarekosten nicht unterschätzen (ebenso wie das Geld für denjenigen, der sie für dich installiert )

Firebird ist nicht wirklich schlecht. Es ist eigentlich sogar absolut fantastisch als embedded Briefcase RDMS.
Aber ehrlich gesagt habe ich mit FB schon zu oft eine korrupte Datenbank Datei erlebt, die Tatsache, dass man die GC sweeps manuell anschubsen muss oder Transaktionen, die irgendwo im Nirwana laufen und Tabllen sperren, obwohl die dazugehörige Connection längst tot ist.
Ich habe sowas nicht ein einziges Mal mit Oracle erlebt, noch nichtmal davon gehört.
Eine hochverfügbare DB würde ich nicht mit FB realisieren wollen, aber für alles darunter ist es sicherlich exzellent.
Außerdem ist FB wahrscheinlich die optimale Wahl wenn AppServer und DB Server die gleiche Maschine sind: der Overhead eines FB servers im Idle-Mode ist praktisch null
Ein Oracle, DB2, whatsoever frisst sich immer die max. Speichermenge, die du ihm zusicherst um sofort sprungbereit zu sein. Deshalb sind solche großen RDBMS absolut uneffizient, wenn sie nicht ihre eigene Maschine(n) haben.

[IBExpert]

Zitat:

Aber ehrlich gesagt habe ich mit FB schon zu oft eine korrupte Datenbank Datei erlebt, die Tatsache, dass man die GC sweeps manuell anschubsen muss oder Transaktionen, die irgendwo im Nirwana laufen und Tabllen sperren, obwohl die dazugehörige Connection längst tot ist.

Korrupte Datenbanken sind seit Firebird 1.x die absolute Ausnahme, wenn man forced writes aktiviert, wenn nicht hat man selbst schuld. Wenn es dann doch auftritt, dann verbunden mit irgeinem Hardwarefehler oder irgendeiner Software auf dem Server, die etwas macht was man nicht machen sollte (Backupsoftware die offenen dateien sichert, Antivirensoftware und sonstiger Kram). Beim dpa Server in Hamburg sind zum Beispiel 300 ständige Verbindungen aktiv, also aktiv arbeitende Redakteure, die entweder selbst Texte schreiben (ca 5000 pro tag) oder noch viel häufiger in den ca 5 Millionen Dokumenten recherchieren. Das ganze läuft 24 Stunden am Tag, weil die eben nie ein Zeitfenster festlegen können, an denen die Redakteure mal eben nicht arbeiten können. Wir haben für die eine Replikation programmiert, die alle Livedaten auf einem zweiten Server stets verfügabr hält, außer durch Hardwarefehler wurde dieser aber noch nie gebraucht. Die Anwender haben beim Umschalten nichts gemerkt.

Garbage Collection läuft übrigens stets im Hintergrund mit ohne das man irgendwas anwerfen muss. Selbst das Sweep Interval ist nur dafür da, das auch Tabellen und Indices verwurstet werden, die eben nicht durch sonstige Clients im Rahmen von SQL Befehlen angepackt werden. Komplette Tabellen habe ich noch nie gesperrt gesehen, ist auch nicht so einfach wegen der Multigenerationsarchitektur. Sperren von toten clients gab es insbesondere beim classic server mal, aber da hat man wohl gerade die ursache gefunden, warum das im Netzwerkprotokoll nicht als toter client erkannt wurde. Meistens sind die angeblich toten Verbindungen, die die Garbage Collection blockieren, aber gar nicht tot, sondern durch unwissenheit eines Programmierers oder admins entstanden.

Bezgl. Garbage Collection: Einfach mal eine Tabelle anlegenn, 100000 Datensätze einspielen, committen, alle datensätze löschen und committen. beim ersten select auf dieser Tabelle kann man in IBExpert den Wert für die Fetches ablesen, das heisst wieviele Recordversionen wurden abgefragt um das Ergebnis zu erstellen. Man sieht beim ersten sql trotz lerrer Ergebnismenge ca. 200000 fetches (2 Version, 1. originalsatz, 2. gelöschte Version). wenn man innerhalb weniger Sekunden das noch mal macht sieht man ca 100000, beim nächsten mal ca 50000 , dann einen Wert nahe 20. durch den Commit beim Löschen macht firebird noch nichts, aber sobald die nächste Transaktion einen der betroffenen Sätze fetcht, wird die dazugehörige Page an den Garbagecollectorthread übergeben und der kümmert sich dann asynchron darum. Und für die tabellen, die nie gefetcht werden ist das Sweep Interval dabei oder der sweep per Kommandozeile. Das gilt übrigens nicht nur für datenpages, sondern auch für Indizes.

unabhängig davon: Oracle ist ganz sicher technischer Marktführer bei den Datenbanken, aber das ist mal Boeing und mal Airbus bei Flugzeugen auch, aber nicht für jeden Zweck bieten die passende Flugzeuge an. In Deutschland gibt es ca 350 Flugplätze, Boeing Maschinen können davon auf maximal 50 landen. Alle anderen sind aber sehr gut anfliegbar mit Cessna, Piper und was da sonst noch so angeboten wird. Und diese können auch auf den großen Airports landen. Nun gut, auch die dicken Flieger können auf den Graspisten landen, aber ob das was dann davon übrig bleibt noch startfähig ist, sei mal dahin gestellt.

ich nehm mal ein ganz banales Beispiel eines Kunden, dessen Software Apothekenlogistik automatisiert. Deren Kunden interessiert nur die Gesamtinvestition und die Stabilität der Gesamtanlage und wie schnell die Dateneingabe, die Verarbeitung, die Anbindung an die POS, die Ausgabe von Reports, etc. ist. Wenn der vom Betrag x nun noch Oracle Serverlizenzen kaufen muss und passende Raidsysteme etc. in die Hardware einplanen muss, ist sein Ertrag für den Hersteller einfach niedriger, weil es dem Kunden einfach egal ist. Anteilig an der Gesamtinvestition kann man da zwar sagen, das das auch nicht mehr viel ausmacht, aber bei so manchem Projekt sind die Nettoerträge trotz großer Projektsummen gar nicht so doll wie man denkt, insbesondere wenn man viele Module selbst einkaufen muss. und wenn die Kiste nicht läuft ist der Hersteller des Gesamtsystems verantwortlich. Ob der nun irgendwelche Tempspaces anpassen muss oder was anderes, was ein unfähiger Admin verbrochen hat, ist dem Kunden egal. Bei der Apothekenlösung hat sich Firebird bewährt, nach anfänglichen Programmierfehlern haben die aufgrund meiner Schulungen und Hinweise Ihre Technik scheinbar im Griff udn nutzen seitdem auch unsere Hotline immer weniger.

ich will eigentlich nur deutlich machen, das nicht immer die eine Lösung das allein selig Machende ist. Bestimmt gibt es Anforderungen, bei denen man mit Oracle die beste Lösung gewählt hat. Aber wie du schon sagst, ähnlich wie beim Flieger muss die Investition immer zum Anwendungszweck passen. Wenn ich von Oldenburg nach Sylt will brauch ein kleiner Flieger ca eine Stunde, es geht auch mit dem Auto in ca 5 Stunden oder mit dem Linienflieger ab Hamburg oder Hannover, wenn denn das gerade einer abfliegt und ich muss da auch erst mal hinkommen.

Bei der dpa hatte man zum Beispiel Bauchschmerzen mit dem Oracle Server auf Laptops, insbesondere weil die Software weltweit im Einsatz ist und viele von den Redakteuren auch offline arbeiten müssen, teilweise auf sehr rustikaler Hardware mit wenig Speicher und wenig festplatte, die man aber mal nicht so eben austauschen kann. Weiterhin war wichtig was passiert nach einem Stromausfall (auf Laptoiops nicht unüblich). Für die Gesamtsoftware war eine Embedded Installation Pflicht, also nur Return drücken und nicht irgendwelche Fragen nach irgendwelches spaces oder sonstwas beantworten. Wenn der Rechner getauscht wird wegen defekt soll es möglichst einfach sein, die db zu übertragen.

Das hat Firebird alles geleistet und man hat sich dafür entschieden. Ich würde aus heutiger Sicht sogar behaupt, das Firebird in Bezug auf die Anzahl installierter Server einen recht hohen Marktanteil hat, weil viele Leute gar nicht wissen, das man den Firebird Server im Hintergrund laufen hat. warum auch? wenn man trotz laufendem Datenbank.

bei Oracle sind übrigens auch Wartungsverträge und Supportangebote recht teuer und wenn man dafür einen kompletten Tagessatz eines Spezialisten bezahlen soll, wenn sich ein Oracle Mitarbeiter (war in wirklichkeit seit 2 Wochen mit dem Studium fertig) beim Kunden per Telefon durchsprechen lassen muss, um auch nur annähernd die mitgelieferten Tools zu bedienen, dann macht das nicht nur mir persönlich bekannte Kunden wütend. Das der Kunde den wegen unfähigkeit nach Hause geschickt hat, hat dazu geführt das der nächste Oracle Mitarbeiter dann erst 4 Wochen später kam. Ich weiss nicht worum es genau ging, aber der EDV Leiter bei dem Laden hat nicht nur in diesem Fall schlechte Erfahrungen mit Oracle gemacht, aber weil deren kaufmännische Software Oracle war, auf Oracle lief und wir für die Produktionsdaten da ran mussten, war es wichtig, das dort irgendwas eingestellt wurde, damit unsere Datenabfragen überhaupt in akzeptabler Geschwindigkeit liefen.
Nun denn, etwas ähnliches kann mit jeder anderen Plattform auch passieren, aber die Anzahl der möglichen Ansprechpartner war aufgrund des Wartungsvertrags sehr begrenzt.

Leute die was taugen sind insbesondere im Oracle Umfeld sehr teuer, dann aber auch oft Ihr Geld wert. Es gibt aber auch da sehr viele mit einem gesunden Halbwissen und wie man weiss ist der Einäugige unter den Blinden der König. das führt eben oft dazu, das man für immer noch viel Geld auf Leute trifft, die von der ganzen Materie nur begrenzt Ahnung haben und oft mehr kaputt machen als helfen.

Die Know How Entwicklung und Verfügbarkeit im Bereich Open Source Datenbanken entwickelt sich aus meiner Sicht immer noch sehr gut weiter. Wenn ein Kunden konkrete Probleme mit dem optimierer in Firebird hat und ich dann per EMail mit Arno Brinkman kommunizieren kann, der den Optimierer entwickelt, dann ist das sicher produktiver auch für meinen Kunden, der oft gar nicht formulieren kann, welches problem das ist und wie man es reproduzieren kann. Die hohen Preise bei Oracle kommen natürlich auch durch di eteuren Hobbies von Herrn Ellison zu stande, aber das sei ihm gegönnt. Ähnlich wie Bill Gates kann er nicht alles falsch gemacht haben in seinem Leben

Gruß
Holger

[Bernhard Geyer]

Zitat von IBExpert:

Ohne das genauer zu beleuchten kann man immer noch an diversen Schrauben drehen, es gibt auch bei firebird nicht nur cache buffers, sondern auch sort memory, sort block size etc.

Und solange man nicht weiß an welchen Schrauben gedreht wurde sind solche Statistiken mit Vorsicht zu genießen. Ich erinnere nur an den Pet-Shop welche für sowas mißbraucht wurde um zu zeigen das .NET oder doch JAVA schneller und besser ist.

Zitat von IBExpert:

Es geht auch nicht immer darum ob dies oder das die beste Plattform ist, sondern ob man mit dem eigenen Businessmodell und den eigenen Programmierwerkzeugen und Kenntnissen etwas konkurrenzfähiges auf die Beine stellen kann.

FULL ACK. Deshalb habe ich ja auch keine DB als die geeignete dargestellt sondern mehrer möglich aufgelistst.

Zitat von IBExpert:

Aus meiner Sicht ist eine plattformübergreifende Implementation aber immer schwieriger,

Ja. Der Basisimplementierungen sind aufwendiger. Wenn man aber mal die DB-Abhänigigkeit in eine Unit für jede DB gekaspelt hat ist es nicht mehr so schlimm.

Zitat von IBExpert:

insbesondere wenn es um große Datenmengen geht. Wenn man weiss das externe Appserver zum Beispiel ca maximal 2000 bis 3000 Datensätze pro Sekunde verarbeiten können, intern jedoch in Stored Procedures auf gleicher Hardware durchaus Werte von 50000 möglich sind (zumindest bei Firebird),

Solche dinke stehen einen mit der passenden Abstraktion immer noch offen. Bisher reicht aber aktuell Prepared-Statemens + "Statement-Cache" aus.

Zitat von IBExpert:

spricht schon so manches dafür, sich auf wenige plattformen festzulegen.

Wenn man dafür einen bestimmten Prozentsatz der Kunden verliert weil diese unbedingt nicht noch eine DB haben wollen ...

Zitat von IBExpert:

Plattformübergreifend kann man nur das nutzen was alle können. Das ist immer ein Kompromiss und der geht fast immer zu Lasten der Performance.

Oder es ist Aufwendiger für alle DB's optimierungen zu finden.

[Daniel G]

Uff...

@IBExpert: Könntest du bitte diese riesigen Bilder in den Anhang packen. Der Beitrag wird dadurch unnötig breit und (nicht nur) ich muss beim Lesen deshalb immer horizontal hin- und herscrollen. Danke.

[IBExpert]

ich hab die gleich durch den link ersetzt. meine Auflösung hier ist 1920*1200, da merkt man das manachmal nicht

[Urba]

Hallo Leute,

Da habe ich ja eine recht heftige Diskussion losgetreten aber das war wirklich sehr informativ. Die Gespräche über MySQL und Firebird lassen mich daher bisher sehr in diese Richtung gehen. Solange man in einem "kleineren" Bereich bleibt scheinen diese beiden wohl keinen schwerwiegenden Unterschied erkennen, allerdings auch durch den Benchmark etwas beeindruckt scheint es so als ob Firebird mit größeren Abfragen, Anpassungen u.ä. zeitlich besser zurechtkommt, oder kommt mir das jetzt nur so vor. Wenn ich die Geschichte(n) der DPA durchlese muss ich schon sagen daß mich das sehr beeindruckt hat.

Wie sieht es denn mit den Installationen/Einstellungen der beiden Systeme aus, müssen dabei viele "schrauben" gedreht werden damit das System optimal läuft und ist dies auch "komfortabel" einstellbar?

Eine weitere Frage wäre folgende :

Kann ich dem Kunden nicht einfach freistellen welches DBSystem er nutzt. Einfach mal angenommen ich habe 3 Server und auf denen ist jeweils ein DBMS installiert und jeweils meine Masteranwendung die die Verbindung für die Clients offen hält. Ich werde ja nur mit SQL arbeiten und alle drei Systeme verstehen diese Sprache. Ist es nicht so daß im Masterprogramm eigentlich nichts zu ändern ist, abgesehen jetzt von IP usw. Sprich ich kann drei mal eigentlich die gleiche Software nutzen. Es kommt dann nur noch auf die Einstellung/Anpassung des DBMS-Systems an wie schnell meine Anfragen durchgehen etc. Sehe ich da nun vollkommen falsch? Wenn ja wie könnte ich es auslegen daß das Programm mehrere verschiedene Systeme nutzen kann?

Gruß
Urba

[ehoffman]

Hallo zusammen,

auch von mir noch ein kurzer Kommentar - habe aber nicht den gesamten Thread (3 Seiten) gelesen, sondern nur mal kurz überflogen. Falls ich also was doppelt schreibe nix für ungut.

Grundsätzlich haben alle der genannten DBMS in bestimmten Bereichen Stärken und Schwächen. Eine pauschale Aussage wie "Oracle bei > 50TB" ist dabei nicht unbedingt richtig. Die vom Ursprungsposter genannten Anforderungen lassen aber auch noch keine wirkliche Entscheidung zu, da sie - wie bereits mehrfach angesprochen - so allgemein und *simpel* sind, dass jedes echte RDBMS sie erfüllen dürfte. Ich weiss, dass diese Aussage nun auch nicht unbedingt weiter hilft. Daher ein paar Links mit "vergleichenden Informationen":

1. Artikel bei Heise Open, zum Thema "Freie Datenbanken im Unternehmenseinsatz - Analyse und Vergleich der wichtigsten Open-Source-Datenbanken"
http://www.heise.de/open/result.xhtm...nk%20Vergleich oder hier
http://www.opensourcejahrbuch.de/200...horstmann.html

Dann gab es in der Ausgabe 08/2006 des Linux Magazins einen Vergleich von Datenbanksystemen (Titelthema). Zusätzlich war dort auch ein Artikel zur Verwaltung sehr großer Datensatzmengen mit Informix zu lesen.

Die Inhaltsübersicht der Ausgabe Linux Magazin 08/2006 ist unter dem Link http://www.linux-magazin.de/Artikel/ausgabe/2006/08 zu finden. Dort kann man auch den Artikel "Sehr große Datenmengen mit Informix effektiv verwalten" (http://www.linux-magazin.de/Artikel/.../informix.html) direkt lesen.
Der Artikel zu Informix ist wirklich lesenswert

Das Heft kann man da auch nachbestellen (denke ich). Da es aber noch nicht soo alt ist könnte es durchaus auch noch bei einigen Händlern rumliegen.

Ich hoffe das hilft etwas weiter.

Viele Grüße, Eike