Hallo Liste, ich habe folgendes vor: - alte e-mail > 3.500 Stück abgespeichert in div. e-mail Programmen (von Outlook Express, Netscape Messenger, Qualcomm Eudora bis hin zu PMMail alles Win bzw. OS/2) sollen in ein "zentrales System" (unter Linux) exportiert werden. - Wie oder was dieses "zentrale System" ist weis ich noch nicht genau, es sollte aber eine DB sein. Welche kostenfreie DB bietet sich unter Linux an? - Wichtig ist für mich auch, das ich die Attachments nicht verliere. - neu ankommende e-mail an z.B.: support@... soll dann nicht nur an den Support weitergeleitet werden sondern auch in dieser DB gespeichert werden. - In einem zweiten Schritt soll dann ein Web Frontend die Informationen darstellen (CGI-Script-Lösung). Hat irgendeiner so etwas ähnliches realisiert bzw. Teilbereiche wie den Export umgesetzt? Für jede Anregung bin ich dankbar. Gruß Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Andreas Olenik wrote:
Hallo Liste,
ich habe folgendes vor:
- alte e-mail > 3.500 Stück abgespeichert in div. e-mail Programmen (von Outlook Express, Netscape Messenger, Qualcomm Eudora bis hin zu PMMail alles Win bzw. OS/2) sollen in ein "zentrales System" (unter Linux) exportiert werden. - Wie oder was dieses "zentrale System" ist weis ich noch nicht genau, es sollte aber eine DB sein. Welche kostenfreie DB bietet sich unter Linux an? - Wichtig ist für mich auch, das ich die Attachments nicht verliere. - neu ankommende e-mail an z.B.: support@... soll dann nicht nur an den Support weitergeleitet werden sondern auch in dieser DB gespeichert werden. - In einem zweiten Schritt soll dann ein Web Frontend die Informationen darstellen (CGI-Script-Lösung).
Hat irgendeiner so etwas ähnliches realisiert bzw. Teilbereiche wie den Export umgesetzt?
Für jede Anregung bin ich dankbar.
Hallo Andreas Nimm LAMP: DB: mySQL zusammen mit Apache und PHP mySQL ist in zusammenhang mit Apache lizenzkostenfrei. PHP kann sehr gut mit Mails und mit Datenbanken. Es sollte daher die ideale Schnittestelle fuer dich sein. -Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Fre, Apr 07, 2000 at 11:45:43 +0200, Marc Schiffbauer wrote:
Andreas Olenik wrote: [Mails in DB exportieren samt Attachments usw.]
Nimm LAMP: DB: mySQL zusammen mit Apache und PHP mySQL ist in zusammenhang mit Apache lizenzkostenfrei. PHP kann sehr gut mit Mails und mit Datenbanken. Es sollte daher die ideale Schnittestelle fuer dich sein.
Das glaube ich nicht. Wenn man Mails oder deren Attachments speichert, dann ist das Fließtext, also unstrukturierte Daten. Relationale Datenbanken eignen sich nicht unbedingt zum Speichern derartiger Daten. Das geht schon damit los, dass char-Felder eine best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der Mail-Anhang Bilder, Programme oder andere binäre Daten enthält? Für diese Art von Daten ist normalerweise der Datentyp BLOB (binary large object) zuständig (kann das MySQL?), mit ihm kann man allerdings ohne Aufsätze auf die DB-Engine kaum arbeiten (also Volltextsuche, Darstellung, Aktualisierung, ...). Auch sind BLOB-Operationen in relationalen DBMS nicht unbedingt schnell. Einige DBMS (Informix) bieten Zusatzmodule dafür (Datablades). Eine andere Möglichkeit ist die Verwendung von objektrelationalen oder objektorientierten DBMS (Poet), da weiss ich allerdings nicht, ob es da freie Produkte gibt. Zur Vorbearbeitung der Mails bietet sich IMHO Perl in diesem Fall mehr an, es hat meiner Meinung bessere Möglichkeiten zur Textmanipulation. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Jan Trippler wrote:
On Fre, Apr 07, 2000 at 11:45:43 +0200, Marc Schiffbauer wrote:
Andreas Olenik wrote: [Mails in DB exportieren samt Attachments usw.]
Nimm LAMP: DB: mySQL zusammen mit Apache und PHP mySQL ist in zusammenhang mit Apache lizenzkostenfrei. PHP kann sehr gut mit Mails und mit Datenbanken. Es sollte daher die ideale Schnittestelle fuer dich sein.
Das glaube ich nicht. Wenn man Mails oder deren Attachments speichert, dann ist das Fließtext, also unstrukturierte Daten. Relationale Datenbanken eignen sich nicht unbedingt zum Speichern derartiger Daten. Das geht schon damit los, dass char-Felder eine
warum nicht?
best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der
zB. typ text. Da kann man dann 4GB reinhauen.
Mail-Anhang Bilder, Programme oder andere binäre Daten enthält?
Für diese Art von Daten ist normalerweise der Datentyp BLOB (binary large object) zuständig (kann das MySQL?), mit ihm kann man
Ja kann es.
allerdings ohne Aufsätze auf die DB-Engine kaum arbeiten (also Volltextsuche, Darstellung, Aktualisierung, ...). Auch sind
PHP?
BLOB-Operationen in relationalen DBMS nicht unbedingt schnell.
Was meinst du jetzt mit Blob-Operationen? Klar, wenn man ne Menge daten hat, dauerts auch laenger, bis die verarbeitet sind. Aber bei Sachen, die uebers Netzt kommen (eMails halt) ist das in dem Fall IMHO zu vernachlaessigen. Ich hab mir zum rumtesten mal ne MP3-DB gebastelt mit der ich MP3s ueber ein Webinterface in die Datenbank (BLOB) hochladen kann. Andersrum hab ich dann ein Apache-Modul geschrieben, mit dem man dann ueber eine virtuelle Verzeichnisstruktur auf dem Webserver die MP3s per streaming direkt aus der DB hoeren kann.
Einige DBMS (Informix) bieten Zusatzmodule dafür (Datablades). Eine andere Möglichkeit ist die Verwendung von objektrelationalen oder objektorientierten DBMS (Poet), da weiss ich allerdings nicht, ob es da freie Produkte gibt.
Ich auch nicht.
Zur Vorbearbeitung der Mails bietet sich IMHO Perl in diesem Fall mehr an, es hat meiner Meinung bessere Möglichkeiten zur Textmanipulation.
PHP ist da auch sehr gut. Es ist in manchen Sahcne sehr an Perl angelehnt. Regex's etc. -Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Sam, Apr 08, 2000 at 07:55:17 +0200, Marc Schiffbauer wrote: [Eignung von LAMP]
Jan Trippler wrote:
Das glaube ich nicht. Wenn man Mails oder deren Attachments speichert, dann ist das Fließtext, also unstrukturierte Daten. Relationale Datenbanken eignen sich nicht unbedingt zum Speichern derartiger Daten. Das geht schon damit los, dass char-Felder eine
warum nicht?
Erst lesen, dann posten. Steht weiter unten.
best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der
zB. typ text. Da kann man dann 4GB reinhauen.
Der Datentyp text ist BLOB. Siehe unten.
Mail-Anhang Bilder, Programme oder andere binäre Daten enthält?
Für diese Art von Daten ist normalerweise der Datentyp BLOB (binary large object) zuständig (kann das MySQL?), mit ihm kann man
Ja kann es.
Gut.
allerdings ohne Aufsätze auf die DB-Engine kaum arbeiten (also Volltextsuche, Darstellung, Aktualisierung, ...). Auch sind
PHP?
Das ist genau das, was ich _nicht_ meine. Mit einem von Dir (oder jemand anderem) verfassten PHP-Script machst Du Folgendes: - Lesen von Datensätzen aus der DB - Bearbeiten der Datensätze - Darstellen der Daten (übers Netz, per Streaming oder sonstwie) Du musst _immer_ die Daten erst aus der DB rausholen. Mit der zu einer relationalen DB gehörenden Abfragesprache SQL kannst Du z. B. nicht Volltextsuche in text-Feldern machen, dafür bietet SQL keine Befehle an. Die like- oder matches-Operatoren greifen dafür nicht. Damit bist du also immer gezwungen, bei BLOBs mittels externer Programme die Daten zu verarbeiten. Die DB dient nur als Datengrab, sonst kann sie nichts mit den Daten anfangen. Mit anderen Datentypen kann SQL eine ganze Menge veranstalten (ausgefeilte Suchstrategien, Rechenoperationen, Typkonvertierungen, Indizierung, ...), mit BLOB nicht.
BLOB-Operationen in relationalen DBMS nicht unbedingt schnell.
Was meinst du jetzt mit Blob-Operationen? Klar, wenn man ne Menge daten hat, dauerts auch laenger, bis die verarbeitet sind. Aber bei Sachen, die uebers Netzt kommen (eMails halt) ist das in dem Fall IMHO zu vernachlaessigen.
Kommt auf die Anzahl der Datensätze und die Leistungsfähigkeit des Severs an. Wenn Du in mehreren GByte unstrukturierten Daten nach einem Begriff suchen willst, dann ist diese Zeit mitnichten mehr zu vernachlässigen - Du bist ja nicht der Einzige auf dem System. Andere suchen ja auch, und zwar gleichzeitig.
Ich hab mir zum rumtesten mal ne MP3-DB gebastelt mit der ich MP3s ueber ein Webinterface in die Datenbank (BLOB) hochladen kann. Andersrum hab ich dann ein Apache-Modul geschrieben, mit dem man dann ueber eine virtuelle Verzeichnisstruktur auf dem Webserver die MP3s per streaming direkt aus der DB hoeren kann.
Da hast Du aber genau das gemacht, was ich oben beschrieben habe: Du hast die DB als Datengrab benutzt. Kann Deine DB z. B. nach Tonfolgen in den MP3-Daten suchen? Das wäre aber die Aufgabe der DB im Sinne des Fragestellers. Die Mails dort sollen ja wohl nicht einfach nur archiviert werden, sondern sie sollen (wenn ich das richtig verstanden habe) z. B. durchsucht, indiziert usw. werden können. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Jan Trippler wrote:
On Sam, Apr 08, 2000 at 07:55:17 +0200, Marc Schiffbauer wrote: [Eignung von LAMP]
Jan Trippler wrote:
best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der
zB. typ text. Da kann man dann 4GB reinhauen.
Der Datentyp text ist BLOB. Siehe unten.
Also das gleiche ist es nicht. text ist ein case insensitives blob.
PHP?
Das ist genau das, was ich _nicht_ meine. Mit einem von Dir (oder jemand anderem) verfassten PHP-Script machst Du Folgendes: - Lesen von Datensätzen aus der DB - Bearbeiten der Datensätze - Darstellen der Daten (übers Netz, per Streaming oder sonstwie)
Du musst _immer_ die Daten erst aus der DB rausholen. Mit der zu einer relationalen DB gehörenden Abfragesprache SQL kannst Du z. B. nicht Volltextsuche in text-Feldern machen, dafür bietet SQL keine Befehle an. Die like- oder matches-Operatoren greifen dafür nicht. Damit bist du also immer gezwungen, bei BLOBs mittels externer Programme die Daten zu verarbeiten. Die DB dient nur als Datengrab, sonst kann sie nichts mit den Daten anfangen. Mit anderen Datentypen kann SQL eine ganze Menge veranstalten (ausgefeilte Suchstrategien, Rechenoperationen, Typkonvertierungen, Indizierung, ...), mit BLOB nicht.
FALSCH. text und blob werden bei mySQL gehandelt wie varchar bzw. varchar binary. Die einzigen Unterschiede sind: - den Daten folgende Leerzeichen werden nicht abgeschnitte wie bei varchar - text und blob koennen keine default-Werte haben. Aber suche in den Feldern und indizierung etc sind sehr wohl moeglich..
BLOB-Operationen in relationalen DBMS nicht unbedingt schnell.
Was meinst du jetzt mit Blob-Operationen? Klar, wenn man ne Menge daten hat, dauerts auch laenger, bis die verarbeitet sind. Aber bei Sachen, die uebers Netzt kommen (eMails halt) ist das in dem Fall IMHO zu vernachlaessigen.
Kommt auf die Anzahl der Datensätze und die Leistungsfähigkeit des Severs an. Wenn Du in mehreren GByte unstrukturierten Daten nach einem Begriff suchen willst, dann ist diese Zeit mitnichten mehr zu vernachlässigen - Du bist ja nicht der Einzige auf dem System. Andere suchen ja auch, und zwar gleichzeitig.
Es geht hier um eMails. Suesse kleine Mails die ein oder andere mit einem Attachment.
Ich hab mir zum rumtesten mal ne MP3-DB gebastelt mit der ich MP3s ueber ein Webinterface in die Datenbank (BLOB) hochladen kann. Andersrum hab ich dann ein Apache-Modul geschrieben, mit dem man dann ueber eine virtuelle Verzeichnisstruktur auf dem Webserver die MP3s per streaming direkt aus der DB hoeren kann.
Da hast Du aber genau das gemacht, was ich oben beschrieben habe: Du hast die DB als Datengrab benutzt. Kann Deine DB z. B. nach Tonfolgen in den MP3-Daten suchen? Das wäre aber die Aufgabe der DB im
Nach Tonfolgen in MP3 dateien. soso. Also wenn eine DB solche spezialfaelle abdecken koennen soll... sowas wirds wohl nie geben.
Sinne des Fragestellers. Die Mails dort sollen ja wohl nicht einfach nur archiviert werden, sondern sie sollen (wenn ich das richtig verstanden habe) z. B. durchsucht, indiziert usw. werden können.
Wie oben beschrieben: Das geht doch.
Jan
-Marc -- +-----Du hast eine nützliche Linuxseite? Du suchst eine?-----------+ | --> http://www.Links2Linux.de <-- | | | +---Registered-Linux-User-#136487------------http://counter.li.org + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Son, Apr 09, 2000 at 01:20:09 +0200, Marc Schiffbauer wrote:
Jan Trippler wrote:
On Sam, Apr 08, 2000 at 07:55:17 +0200, Marc Schiffbauer wrote: [Eignung von LAMP]
Jan Trippler wrote:
best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der
zB. typ text. Da kann man dann 4GB reinhauen.
Der Datentyp text ist BLOB. Siehe unten.
Also das gleiche ist es nicht. text ist ein case insensitives blob.
Häh? Was will uns der Dichter damit sagen? Ein Blob ist einfach eine Sammelbüchse für unstrukturierte Daten. Wenn er case-irgendwas wird, dann ist es eigentlich kein Blob mehr. [Blobs und SQL]
FALSCH. text und blob werden bei mySQL gehandelt wie varchar bzw. varchar binary. Die einzigen Unterschiede sind:
- den Daten folgende Leerzeichen werden nicht abgeschnitte wie bei varchar - text und blob koennen keine default-Werte haben.
Aber suche in den Feldern und indizierung etc sind sehr wohl moeglich..
Das ist dann wohl eine sehr spezielle Art von Blob. Wie willst Du z. B. Mime-kodierte Attachments von Mail handhaben? Da dürften sich Indizes oder like-Operatoren doch ziemlich verloren vorkommen. [Datenvolumen ...]
Es geht hier um eMails. Suesse kleine Mails die ein oder andere mit einem Attachment.
Und wieviele davon?
Nach Tonfolgen in MP3 dateien. soso. Also wenn eine DB solche spezialfaelle abdecken koennen soll... sowas wirds wohl nie geben.
Du bist nicht auf der Höhe der Zeit. Jan P.S.: Ich glaube wir sind langsam OT, wir sind nämlich die einzigen in diesem Thread. Außerdem scheinen sich unsere Erfahrungen doch in unterschiedlichen Universen zu bewegen. Wenn es dazu noch was mitzuteilen gibt, dann am besten per PM. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Jan Trippler schrieb am 09.Apr.2000:
On Son, Apr 09, 2000 at 01:20:09 +0200, Marc Schiffbauer wrote:
P.S.: Ich glaube wir sind langsam OT, wir sind nämlich die einzigen in diesem Thread.
Dann muß ich mich doch schnell mal einmischen. ;))
Außerdem scheinen sich unsere Erfahrungen doch in unterschiedlichen Universen zu bewegen.
Das wird es sein. Für die Meisten ist eine Datenbank doch etwas, wo man schön sortiert seine Platten oder Bücher oder sonstwas Sammlung ablegen kann und auch noch eine nette Suchfunktion hat. Dabei wird eine DB erst interessant, wenn hunderte Leute gleichzeitig auf sie zugreifen und auch noch auf den gleichen Datensatz. Dort evtl. auch noch ein bedingtes Rollback ausführen und solche Späße mehr. Und ein Journalingsystem soll natürlich auch noch laufen. Dann fängt DB erst richtig an. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Apr.2000:
On Son, Apr 09, 2000 at 01:20:09 +0200, Marc Schiffbauer wrote:
P.S.: Ich glaube wir sind langsam OT, wir sind nämlich die einzigen in diesem Thread.
Dann muß ich mich doch schnell mal einmischen. ;))
Mist. :-)
Außerdem scheinen sich unsere Erfahrungen doch in unterschiedlichen Universen zu bewegen.
Das wird es sein. Für die Meisten ist eine Datenbank doch etwas, wo man schön sortiert seine Platten oder Bücher oder sonstwas Sammlung ablegen kann und auch noch eine nette Suchfunktion hat.
Das beziehe ich jetzt aber nicht auf mich.
Dabei wird eine DB erst interessant, wenn hunderte Leute gleichzeitig auf sie zugreifen und auch noch auf den gleichen Datensatz. Dort evtl. auch noch ein bedingtes Rollback ausführen und solche Späße mehr. Und ein Journalingsystem soll natürlich auch noch laufen.
Dann fängt DB erst richtig an.
Ist klar. Aber dann hab ich auch keine mySQL mehr. Die kann naemlich kein Rollback. Hier ist dann natuerlich Oracle dran. Welche DBs, die auf Linux laufen, koennen son noch Rollback, gesicherte Transaktionen etc., wie Oracle? Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, Apr 10, 2000 at 09:47:06 +0200, Marc Schiffbauer wrote:
Bernd Brodesser wrote:
* Jan Trippler schrieb am 09.Apr.2000:
P.S.: Ich glaube wir sind langsam OT, wir sind nämlich die einzigen in diesem Thread. Dann muß ich mich doch schnell mal einmischen. ;)) Mist. :-)
Genau ;-) [Transaktionen]
Hier ist dann natuerlich Oracle dran. Welche DBs, die auf Linux laufen, koennen son noch Rollback, gesicherte Transaktionen etc., wie Oracle?
Informix (SE oder Dynamic Server, je nach Geschmack), Adabas, Interbase z.B. Und wenn wir schon dabei sind: In einer Multi-User-Umgebung sind saubere Sperr-Strategien und Isolationslevel mindestens genauso wichtig wie Transaktionshandling. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Jan Trippler wrote:
On Son, Apr 09, 2000 at 01:20:09 +0200, Marc Schiffbauer wrote:
Jan Trippler wrote:
On Sam, Apr 08, 2000 at 07:55:17 +0200, Marc Schiffbauer wrote: [Eignung von LAMP]
Jan Trippler wrote:
best. Maximallänge haben (z. T. nur 255 Zeichen, ich weiß jetzt aber nicht, wie das bei MySQL aussieht). Was passiert, wenn der
[blob und text]
Häh? Was will uns der Dichter damit sagen? Ein Blob ist einfach eine Sammelbüchse für unstrukturierte Daten. Wenn er case-irgendwas wird, dann ist es eigentlich kein Blob mehr.
ACK. Bei mySQL ist es eben ein bischen anders.
[Blobs und SQL]
FALSCH. text und blob werden bei mySQL gehandelt wie varchar bzw. varchar binary. Die einzigen Unterschiede sind:
- den Daten folgende Leerzeichen werden nicht abgeschnitte wie bei varchar - text und blob koennen keine default-Werte haben.
Aber suche in den Feldern und indizierung etc sind sehr wohl moeglich..
Das ist dann wohl eine sehr spezielle Art von Blob. Wie willst Du z. B. Mime-kodierte Attachments von Mail handhaben? Da dürften sich Indizes oder like-Operatoren doch ziemlich verloren vorkommen.
Auch ACK. Aber in binaer-Daten, ob sie nun Mime-codiert sind oder nicht (BTW: PHP kann MIME-(de)codieren) will ich doch eigendlich nichts suchen oder? Vergleichen sollte aber sehrwohl klappen. Mann muss sich nur vorher darauf einigen, ob solche Sachen grundsaetzlich kodiert oder unkodiert gespeichert werden. Wenn Dateien als Attachement vorliegen, kann man ja auch den Dateinamen in einem Extrafeld speichern... Ich mein klar sind Operationen mit grossen Datensaetzen (ist realtiv, klar. Ich meine jetzt mehrere MB) langsam. Vor allem mit unstrukturierten Daten. Aber wenn es gefordert wird... Wie wuerdest du es denn machen?
[Datenvolumen ...]
Es geht hier um eMails. Suesse kleine Mails die ein oder andere mit einem Attachment.
Und wieviele davon?
Egal. Das ist doch dann letztendlich eine Hardwarefrage, oder?
Nach Tonfolgen in MP3 dateien. soso. Also wenn eine DB solche spezialfaelle abdecken koennen soll... sowas wirds wohl nie geben.
Du bist nicht auf der Höhe der Zeit.
Also die Datenbanken, die ich kenne, haben solche Funktionen nicht im Bauch. Oder meinst du, binaer vergleichen? Das geht natuerlich.
P.S.: Ich glaube wir sind langsam OT, wir sind nämlich die einzigen in diesem Thread. Außerdem scheinen sich unsere Erfahrungen doch in unterschiedlichen Universen zu bewegen. Wenn es dazu noch was mitzuteilen gibt, dann am besten per PM.
Jetzt ist Bernd ja noch dabei. Aber trotzdem OT. Ich will mich jetzt ja nicht mit Dir pruegeln (virtuell) ;-) Wie wuerdest du denn ansetzten, wenn es darum geht binaer-daten (Attachements) oder lange Mails (ja, unstrukturierte Daten...) zu verwalten? Man kann sie natuerlich auch im Dateisystem speichern, aber ob das besser ist ?!? Gruss Marc -- .~. *** /V\ ************************************************************ * // \\ Center of Excellence Linux * Marc Schiffbauer * * /( )\ * Siemens ITS GmbH & Co. OHG * ** ^`~'^ *********************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, Apr 10, 2000 at 09:42:59 +0200, Marc Schiffbauer wrote: [MySQL und Blobs]
Jetzt ist Bernd ja noch dabei. Aber trotzdem OT. Ich will mich jetzt ja nicht mit Dir pruegeln (virtuell) ;-)
Schade, ich habe mir schon die virtuellen Ärmel hochgekrempelt ;-)
Wie wuerdest du denn ansetzten, wenn es darum geht binaer-daten (Attachements) oder lange Mails (ja, unstrukturierte Daten...) zu verwalten? Man kann sie natuerlich auch im Dateisystem speichern, aber ob das besser ist ?!?
Da gibt es IMHO mehrere Varianten, je nach Umfang der Aufgabe (der Aufwand muss sich ja letztendlich rechnen): - bis zu einem bestimmten Datenvolumen (das muss man einfach mal probieren) ist sicher die Datenhaltung in einem normalen Dateisystem ein gangbarer Weg. Dann kann man mit der ganzen Macht der Linux-Werkzeuge und Scriptsprachen auf die Suche gehen. - Es gibt ein paar DBMS unter Linux, die auch mit Blobs umgehen können, die kann man mal testen (mir fällt da z. B. TransBase ein) Dann muss man aber AFAIK mit Löhnware rechnen. - Es gibt zu relationalen DBMS wie Informix objektorientierte Aufsätze (bei IF heißen sie Datablades), mit denen sowas möglich sein soll, das allerdings nur vom Hörensagen; keine persönlichen Erfahrungen. - Man kann die Daten so aufbereiten, dass sie auch in relationalen DB eine Art Volltextsuche ermöglichen, das führt aber schnell zu sehr grossen Tabellen. Ein Patentrezept kann man nicht aufstellen, da spielen zu viele Faktoren rein: - Hardware (finanzieller Spielraum) - DBMS (dito: Finanzen) - Datenvolumen, Wachstum des Datenbestandes - gewünschter Funktionsumfang bei der Aufbereitung, Abfrage der Daten - Struktur der Daten (ich stelle mir den Aufwand geringer vor, wenn die Daten z. B. aus einem Fachbereich stammen, also homogener aufgebaut sind) - vorhandenes KnowHow und verfügbare Zeit / Entwicklungskapazitäten - ... So, nun sollten wir aber wirklich Schluss machen, das gerät langsam zu einer Art Projektmeeting. Um genauer werden zu können muss man mehr Informationen haben und das führt in der Liste zu weit. Gern per PM weiter. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
andreas＠olenik.de -
B.Brodesser＠online-club.de -
Jan.Trippler＠t-online.de -
marc.schiffbauer＠links2linux.de