Ich denke man muss abwägen was man braucht und in 99% der Fälle kommt eine Eigenentwicklung schlechter weg. Der wichtigste Faktor sind Zeit und Kosten und das ist bei einem vernünftigen DBMS nicht unerheblich. MySQL & Co sind fertig und können frei verwendet werden, das eigene System muss erst noch entwickelt werden.

Joe, der Wartungsaufwand ist kein Argument für deine Eigenentwicklung. Software hat Fehler, immer. Bei weit verbreiteter Software ist es wahrscheinlicher, dass Fehler gefunden und behoben werden. Bei der Eigenentwicklung kennt niemand den Code, aber das steigert nicht die Sicherheit, es wird auch hier Schwachstellen geben und security by obscurity funktioniert nicht.

Ein DBMS hat den Vorteil, für alle möglichen Aufgaben geeignet zu sein, das wirkt sich im Umkehrschluss sicher auf die Geschwindigkeit aus. Eine Spezialanfertigung wird ihre Aufgabe schneller erledigen. Bleibt die Frage nach der Flexibilität und hier hat vermutlich das DBMS wieder die Nase vorn.

Wer keinen eigenen Server hat, kann Sonderwünsche gleich vergessen, ebenso wer Software massenweise an den Mann bringen will.

Ich wage zu bezweifeln, dass David eben schnell C lernt und dann in der Lage ist ein DBMS zu schreiben welches schnell, sicher und flexibel ist. Wenn das so einfach wäre, dann würde wohl niemand auf MySQL, PostgreSQL usw. setzen.

Naja, ansehen kann man es ja nicht. Aber ich weiß wie SQL Abfragen aussehen und habe früher selber versucht (wegen vermeintlicher Performance) sowas selber zu bauen. Daher habe ich meine Zweifel.

Es kann natürlich sein, dass Schepper für seine Daten ein eigenes Indexformat entwickelt hat und einen ausgeklügelten Cache. Das ist ja das was ein DB System macht. Aber allein für sowas wie das Forum hier, brauchst du dann schon eine sehr komplexe Anwendung um das umzusetzen was du in einer SQL Abfrage machen kannst.

Aber ich bestreite nicht, dass wenn du eine Anwendung schreibst, die nichts anderes als eine einzige Aufgabe erfüllt und auch in Zukunft nicht anderes machen soll, dass du dann unter Umständen schneller sein wirst.

@Scheppertreiber:

Hast du schon einmal einen direkten Vergleich zwischen MySQL und deiner eigenen Lösung gemacht, könntest du irgendwelche Fakten liefern? Ich finde deinen Sonderweg über "C" und der eigenen Datenbanklösung schon seit längerem sehr interessant.

Ein solcher Vergleich wäre sicherlich sehr aufschlussreich.

__________________
Mit freundlichen Grüssen "Pascolo"

Guter Webspace eSport Topliste Meine Lesezeichen Meine Spielwiese

Ich habe es mal probiert ...

Allerdings "meins" vs SQLite (dürfte aber nicht so ein großer Unterschied sein).

Einen Kunden habe ich komplett auf SQL laufen. Es läuft zwar flott, könnte aber
noch zulegen. Stärke von SQL ist die Flexibilität, klar. Füge ich einer Datenbank
eine Spalte hinzu muß ich aber auch die entsprechenden Programme anpassen.
Komplexere Anfragen sind auch etwas einfacher.

Nur die Laufzeiten ... Anlayse "Belegmenge PDF/XML/Text" (SQLite-db mit 2 GB)
läuft locker eine Stunde. Egal, läuft nur einmal ....

Meine db *schmacht*

Zweck: Revisionssichere Ablage und Archivierung gleichartiger Textstreams und
XML/PDF-Daten, Aufruf über's www.
Datenmenge: bis 100 Mio Belege / Jahr.

Probleme:

* Habe ich eine große db (ich könnte PDFs ja zB als BLOB direkt einlagern)
ergibt ein Monster das man nicht mal mehr sichern kann (kopiere mal eine Datei
von > 100 GB auf ein Band oder so).

* Robustheit: wenn's irgendwo crasht sollte es ohne Probleme irgendwie wieder
zum Laufen gebracht werden können ohne alle Daten neu einzulesen

* Flexibilität: es gibt ungeahnte Möglichkeiten, Daten falsch aus einem Rechner
auszulagern, von kreativer Codierung der Umlaute bis vergessenen Form Feeds,
dazu absolut irre Datenformate.
Also per Script alles steuern.

Damit es mit der Datensicherung nicht klemmt, lege ich die Daten tageweise
in Containern ab, jeweils mit den zugehörigen Kenndaten als Indexrohdaten.
Aus den Indexrohdaten erstelle ich mir dann eine Art Suchindices, die in der
Praxis einfach Textdateien mit allen Indexbegriffen, aber unterschiedliche
Sortierung sind. Bei der Suche gehe ich in die Mitte, vergleiche größer oder
kleiner, dann springe ich wieder in die Mitte vom Rest. Nach 7-9 Vergleichen
habe ich den ersten Record der paßt. Dann "solange es paßt" einach als
table ausgeben.

Klickt der User einen Records an, wird das PDF erzeugt bzw ausgegeben.

Eigentlich ganz einfach, es gibt aber Tücken ...

zB bei eingen Kunden komplett durchgeknallte Zugriffsrechte die nur durch einen
saugeilen Drogenrausch erklärbar sind.

--

Die Belege kommen nachts per ftp, die Vearbeitung startet dann automatisch.

--

Die ersten Systeme hatte ich mit Btrieve als db laufen, es war nach 2 mon
absehbar, daß alleine der Datenimport zum Jahresende knapp 20 h gelaufen wäre
(exklusiver Zugriff, sonst dauert's noch länger).

Also mußte etwas anderes her

--

Die Laufzeitunterschiede sind erklärbar:

* Da es ein Archiv ist, werden keine Daten mehr geändert. Alle
Synchronisationen, Locks etc entfallen.

* Btrieve oder SQLIte aktualisieren ständig die Indices, bei mir läuft das einmal
am Ende.

* Es werden nur Strings gespeichert, nichts wird konvertiert

* Die Indexdatenbanken laufen mit fester Satzlänge, kein Paging notwendig.

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Zunächst einmal glaube ich, dass Joe durchaus in der Lage ist sein System für seinen Anwendungsbereich einzuschätzen, das mal vorweg.

Bei meiner Suche nach der Geschwindigkeit von SQLite bin ich auf folgende Seite gestossen, die jeder wohl sofort finden würde: SQLite Database Speed Comparison
Ich betrachte die Vergleiche etwas kritisch, da die Benchmarks vom Hersteller durchgeführt wurden, aber ich denke zumindest zum Teil werden die Werte stimmen.

Wichtig finde ich die Unterschiede bei ein- bzw. ausgeschaltetem Index bzw. nosync bei sqlite.

Ich denke ganz einfach, dass bei Joe's Vergleichen evtl. von den DB-spezifischen Optionen kein Gebrauch gemacht wurde?
Von Mysql weiß ich, dass man den Index aus- und wieder einschalten kann, um sehr viele INSERTs deutlich zu beschleunigen, bei sqlite scheint dies die nosync-Option zu sein.
@Joe: Hast Du dies mal ausprobiert?

@Joe: Hast Du bei den Vergleichen tatsächlich die PDFs in der Datenbank gespeichert? Ich weiß zwar, dass die DBs die Möglichkeit bieten BLOBs zu speichern, aber bisher ist mir noch kein Grund eingefallen, weshalb man die Datenbank tatsächlich mit sowas belasten sollte. Ich würde die DB hier nur als Hilfe für die Suche/Filter/sonstiges verwenden, die Dateien aber direkt auf der Platte speichern und in der DB leidglich einen Verweis zum Speicherort. Die DB dürfte somit deutlich kleiner (und wohl auch schneller) sein.
Natürlich muss man so immer zwei Dinge im Backup berücksichtigen, DB und Dateibestand, aber das ist imo die einzig sinnvolle Art da dran zu gehen.
Wenn die Idizes dann noch korrekt gesetzt sind, sollte der Geschwindigkeitsunterschied bei weitem nicht mehr so riesig sein.

Die PDF habe ich in Container gepackt. In der db sind dann die Refenzen auf
diesen Container. Leg mal 10 Mio Files in eine Dateisystem und sichere dann

Im SQL-Archiv sind es im Moment ca 6,5 Mio Belege mit knapp 700 GB an PDF.
Die Performance geht eigentlich (in Marokko hängt noch eine Buchungsabteilung
über ISDN dran, die merken das eh nicht ).

Die Laufzeit beim Datenimport ist eigentlich wurscht, das passiert nachts und
solange das bis 4 h fertig ist habe ich kein Problem. Entscheidend sind eher die
Suchzeiten, da spielen wieder die Zugriffsrechte eine Rolle.

Im SQL-Archiv sind relativ viele kleine Datenbereiche, im "richtigen" große
Mengen mit wenigen Datenbereichen. Mit SQL kann ich bei relativ kleinen
Datenmengen die Flexibilität ziemlich ausfahren, die hilft dann da auch.

Was ich gehört habe, hat SQLite Performance-Probleme bei großen Datenmengen,
schaunmerma.

Interressant wäre wirklich mal ein Vergleich mit mySQL.

---

Das "richtige" System läuft seit ca 5 Jahren im Livebetrieb, es werden 10 Jahre
die Daten vorgehalten. Ich 5 Jahren wird das erste Mal gelöscht ... hehe ...

Keine Migration, keine db-Updates wo nix mehr geht etc.

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Das ist wirklich eine grosse Datenmenge. Hut ab, wenn dein eigenes System derart gut funktioniert.

__________________
Mit freundlichen Grüssen "Pascolo"

Guter Webspace eSport Topliste Meine Lesezeichen Meine Spielwiese

Das ist nur das "kleine" Archiv. Das große läuft mit 20"-Platten

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Hui, ich wollt hier keien Grundsatzdiskusion lostreten, dennoch sind die einzelnen Meinungen sehr interessant.

Es handelt sich um eine bereits existierende MySQL Datenbank. Die Objekttabelle hat zur Zeit rund 13.000 Einträge, also nix großes. Es soll halt die Möglichkeit bestehen, vereinzelt auch mehr Informationen über die Objekte abzulegen. Ich werd wohl die eingangs beschriebene Methode verwenden.
In den bereichen sollte die Performance von MySQL völlig ausreichen.

__________________
github | http://dnaber.de