[wish] Neues Datenbankformat für Maildatenbank: z.B. SQlite

Hi!

Ich wünsche mir ein anderes "Datenbankformat": statt der bisherigen Ordnerstruktur wäre mir eine Struktur in einer 'ordentlichen' Datenbank, z.B. sqlite o.ä., lieber. Inkl. des Adressbuches, bitte. Apple macht 's vor: deren Mailprogramm Mail benutzt sqlite.

Eintrag beim Ritlabs-Bugtracker. Wer möchte, kann meinen Wunsch dort unterstützen.

Hi!

SQLite ist vollwertiges SQL, siehe SQLite, bzw. hier: SQLite SQL Language Syntax Diagrams. Ferner ist SQLite Public Domain-Software.

Jemand von Ritlabs hat auf meinen Vorschlag geantwortet, allerdings hab ich die Antwort nicht so wirklich verstanden. Vielleicht hat jemand mehr Erfahrung mit solchen Antworten und kann mir diese übersetzen. Die Antwort ist hier: Ticket 0007350: Replacement for the folder based maildatabase by a real database - like SQlite. Die Notiz von Ivan Bolhovitinov von 08:42 Uhr verstehe ich nicht.
Auch nicht, warum er EML durchsuchen will.

Das die Dateianhänge ein Problem darstellen, da diese ggf. als BLOB abgelegt werden müßen, stimmt schon. Aber Apples Mail machts vor - irgendwie geht das, genauso wie die Bookmarks von Firefox/Iceweasel seit dem Versionssprung zur v3.x auch in SQLite vorliegen.

Und es muß nicht unbedingt SQLite sein, daß war lediglich eine $Variable für ein mögliches RDBMS, um von der Ordnerstruktur und dem nicht dokumentierten Binärformat weg zu kommen.

Und zuletzt:
Meinetwegen ist das OK, wenn die Ritlaboranten zumindest das (Binärformat) mal vernünftig dokumentieren würden. Dann könnte man das wenigstens mal vernünftig in mein debian/KDE einbinden. Aber das ist eine andere Geschichte.

Hi Bernd!

Zitat

Ich versteh die Antwort auch nicht so recht :hae: Schon alleine der Quatsch, dass SQL nichts suchen könnte.

Ja, komisch. Hab schon gedacht, daß ich keine Ahnung habe, aber die Antworten haben mich mehr verwirrt als geholfen. Gut, der Antwortende kann kein Englisch, aber die Inhalte habe ich so verstanden, daß eine auf SQL-basierte Lösung alles umständlicher, kompliziert und überhaupt, macht.
:devil: Oder böse: der hat keine Ahnung von SQL.

Anyway: vielleicht wünsche ich mir nochmal eine bessere Dokumentation des bisherigen Formates.

Hi!

Nachgereicht:

Warum habe ich den Beitrag überhaupt geschrieben, bzw. was ist der Vorteil einer Datenbank im Hintergrund?
(Das hatte ich am Anfang, als ich diesen Thread begonnen habe, ganz vergessen).

1.) weniger Dateien beim Backup
2.) mehr Sicherheit durch RDBMS - relationales Datenbanksystem
3.) schneller, denn die interne Verwaltung obliegt der Datenbank (DB)
4.) Zugriff auf die Infos aus anderen Programmen heraus
5.) The Bat! Adressbuch könnte das Windows Adressbuch ersetzen
6.) Portabilität, d.h. die DB kann z.B. (besser) unter Linux benutzt werden

Das war meine Motivation, als ich heute morgen den Thread eröffnet und einen Eintrag in den Bugtracker/Wishlist der Ritlaboranten geschrieben habe.

Vielleich erhört jemand mein bitten ... ist doch bald Weihnachten!
:gaehn:

Der Link zum Ritlabs-Bugtracker für diesen Wunsch folgt hier nochmal:

URL: [wish] Neues Datenbankformat für Maildatenbank: z.B. SQlite

Hi Gwen!

Zitat

So manches hätte ich bitte gern von dir gewußt, weil deine Aufzählung mich da im Unklaren lässt:

1) Wieso weniger? Weil alles in eine Datei gepackt wird oder wie?
2) Was ist denn bitte an RDBMS sicherer als an der derzeitigen Datenbank?
3) Schneller für was? Suche? Laden der Daten? Löschen?
4) Welche Infos? Maildaten?
5) Wer benutzt denn das Windows-Adressbuch bitte? Ich jedenfalls nicht.
6) Ritlabs hat keine Portierung für Linux vor.

Was soll denn bitte in die Datenbank rein? Alles was vorher beim Account in einzelne Dateien herumgewuselt ist?

Alles anzeigen

Ich versuche mal, meinen Wunsch, denn daß ist es zur Zeit doch wohl nur, ein wenig zu spezifizieren. Deshalb mal meine Antworten auf Deine Fragen:

[list type=decimal]
[li]Genau, bei SQLite wäre das eine Datei, bei anderen Datenbanken ggf. ein paar mehr.[/li]
[li]Die Prüfung der Datenkonsistenz, d.h. Vorliegen von beschädigten Dateien, wird nicht vom Programmierer geleistet, sondern vom Datenbanksystem.[/li]
[li]Schneller deshalb, weil die Datenbank in einem eigenen Prozeß/Thread läuft. Ein SELECT und Konsorten brauchen dann (relativ) weniger Zeit, die sie sich nicht mit dem Programm, hier The Bat! teilen müßten, sondern direkt vom OS (=Betreibsystem) zugewiesen bekämen. (Klar muß sich dieser Prozeß mit anderen insgesamt die CPU teilen, doch das ist nicht gemeint).[/li]
[li]Infos = Maildaten. Endlich mal eine geeignete Schnittstelle, die es zuließe von jedem beliebigen Programm auf die Maildaten etc. zuzugreifen.[/li]
[li]Warum eigentlich nicht? :denk: Genau! Ich arbeite bekanntlich unter debian/KDE/wine mit The Bat!, und ich nutze das KAdresbuch für jeden erdenklichen Zweck. So war 's bei Windows auch gedacht. Wäre doch Klasse, wenn man das Win-Adressbuch einfach durch das von The Bat! ersetzen könnte, oder?[/li]
[li]Eben weil es wahrscheinlich nie eine Linux-Protierung von den Ritlaboraten geben wird, will ich eine vernünftige Schnittstelle zu meinen (Mail)-daten.[/li]
[li]Ja, auch die Nutzer-/Accountverwaltung wäre auf Datenbankbasis besser zu managen.[/li]
[/list]

Das wären meine Ideen, die durchaus auf Erfahrungen mit anderer Software, Stichwort: Fakturierung, die auf einer Firebird-Datenbank basiert, beruhen.

Lange Rede - kurzer Sinn: ich wünsche mir eine vernünftige Schnittstelle zum Programm The Bat!. Hier eben am besten dort, wo die Daten abgelegt werden, eben in der Maildatenbank. Alternativen wären so Sachen wie COM oder old-fashioned: DDE/OLE.

Deshalb nochmal das hier:

Der Link zum Ritlabs-Bugtracker für diesen Wunsch folgt hier:
URL: [wish] Neues Datenbankformat für Maildatenbank: z.B. SQlite