Hallo DB-Webtech.de, On Sat, Jul 05, 2003 at 06:31:00PM +0200, DB-Webtech.de wrote: [..schrott..] was soll das denn für eine Antwort sein? Konnte das einer ordentlich lesen? Greetings Daniel -- #!/bin/bash X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-VIRUS-TEST-FILE!$H+H* # for file in *.sh ; do head -n 3 $0 > $file ; done

Hallo, Adalbert, On Sat, Jul 05, 2003 at 05:55:21PM +0200, Adalbert Michelic wrote:

* On Sat, 05 Jul 2003 at 18:38 +0200, Daniel Lord wrote:

...

On Sat, Jul 05, 2003 at 06:31:00PM +0200, DB-Webtech.de wrote:

| X-Mailer: IncrediMail 2001 (1800838)

Dieses IncrediMail ist eine Seuche, schlimmer als Outlook-Varianten, die es jemals geben wird. Wenn wer was zum Lachen sucht, empfehle ich den Besuch der Website dieses Produkts, Adresse liegt bei Google auf Lager. Achja, da ist natürlich Flash notwendig.

*gnaaaa* ... *wegwerf* http://www.incredimail.com/english/splash.html Flash habe/will ich nicht. Ist aber auch so schon zum _wegwerfen_ :0 * ^X-Mailer: IncrediMail /dev/null Greetings Daniel -- I live in Shadow, I roam through your dreams I'm making that noise when you think you hear screams -- mDarkstorm

Hallo, On Sun, 06 Jul 2003, Joerg Rossdeutscher schrieb:

Moin,

Am Sam, 2003-07-05 um 20.32 schrieb Daniel Lord:

...

On Sat, Jul 05, 2003 at 05:55:21PM +0200, Adalbert Michelic wrote:

...

* On Sat, 05 Jul 2003 at 18:38 +0200, Daniel Lord wrote: | X-Mailer: IncrediMail 2001 (1800838) Dieses IncrediMail ist eine Seuche, schlimmer als Outlook-Varianten, *gnaaaa* ... *wegwerf* http://www.incredimail.com/english/splash.html

Nicht so eilig - euch entgeht was! Ich zitiere: ---------------------------------------------- Text-animierte smileys,Ihre Text zu animieren Vibrierend ankommende E-Mail-Benachrichtigungen ständig aktualisierten Grafikinhaltbank. ----------------------------------------------

*ROTFL* *haben will* *NOT!* -dnh -- 66: WWW in bunten Bildern wenig Klarheit, viel Irrtum und ein Fünkchen Wahrheit (Johann Wolfgang v. Goethe)

Hallo, On Sun, 06 Jul 2003, Manfred Tremmel schrieb:

Am Sonntag, 6. Juli 2003 20:31 schrieb David Haller:

...

On Sun, 06 Jul 2003, Joerg Rossdeutscher schrieb:

...

---------------------------------------------- Text-animierte smileys,Ihre Text zu animieren Vibrierend ankommende E-Mail-Benachrichtigungen ständig aktualisierten Grafikinhaltbank. ----------------------------------------------

*ROTFL* *haben will* *NOT!*

Ach David, läst sich sowas mit mutt denn nicht konfigurieren?

[X] DAS will ich garnicht erst wissen!!!!!!1

Ich denk mal sowas ist deutlich wichtiger, als RFC konforme Mails zu erstellen ;-)

*lol* -dnh PS: auf Animationen/Vibrationen kann ich wirklich verzichten, im Gegenteil, mich packt das grausen, wenn ich daran denke... -- 282: Perl Der geglückte Versuch, einen braindump direkt ausführbar zu machen. (gefunden von Alexander Schreiber)

Sebastian Giffhorn wrote:

Hallo Daniel Lord,

Hi Sebastian [...]

DL> Hallo DB-Webtech.de,

Die Initialien gehören da auch nicht hin. Eine einfaches '>' reicht. [...]

Sorry !

War keine Absicht mit dem HTML. Naja IncrediMail is mal direkt von der Platte runtergeflogen. Ist das jetzt so OK ??? (Diesmal kein HTML??)

MfG Sebastian Giffhorn mailto:webmaster@db-webtech.de

Das 'mailto:' kann auch eingespart werden. Wer Dir eine Mail schicken will, kopiert sich das bestimmt nicht in die To:-Zeile, sondern macht einfach ein Reply und hat Deine Adresse automatisch. Gruß Martin P.S. Noch was für die anderen, die es betrifft: Die Mailinglistenadresse gehört nicht ins Cc:-Feld, sondern alleinstehend ins To:-Feld. Wer sich unbedingt eine Copy selbst oder anderen zusenden will, kann das als Bcc erledigen und stört damit nicht die Liste. -- Ich lösche ungelesen alle PMs aus der Liste und beantworte danach keine weitere Fragen.

Adalbert Michelic wrote: [...]

Filtere nach 'X-Mailinglist: suse-linux', dann hast Du Deine Ruhe

Ja klar, man kann natürlich immer den kleinsten gemeinsamen Nenner suchen. Aber der sollte das Thema Linux sein und nicht ein Filter- kriterium.

und brauchst keine solchen obskuren Regeln aufstellen, die sowieso

Findest Du es wirklich so 'obskur'?

$BIGNUM Leuten egal sind, weil es ihnen nichtmal auffallen würde,

... oder die, die sich dafür halten. ;)

daß da einer die Listenadresse nicht in To sondern in Cc oder Bcc geschrieben hat.

Ne, die gehen teilweise so schlampig mit den (Umgangs-)Formen dieser Liste um, daß man sich manchmal fragt, ob die wirklich so eine $BIGNUM sind. Whre Größe mache ich jedenfalls an einer Professionalität auf ganzer Linie fest. Ich könnte einige Namen dazu nennen, will ich aber hier nicht, um die anderen dann nicht genannten nicht zu kränken, falls die zu empfindlich sind. ;) Gruß Martin -- Ich lösche ungelesen alle PMs aus der Liste und beantworte danach keine weitere Fragen.

Hi, * Am 06.07.2003 (12:42) schrieb Martin Falley:

Adalbert Michelic wrote: [Mal wieder die Diskussion wie filtere ich]

(1) Von den Entwicklern der verschiedenen Mailinglisten Verwaltungssoftware wurde die Möglichkeit ersonnen Mailinglisten spezifische Header einzufügen. (2) Es ist jedem selber überlassen, ob er dieses Angebot annimmt. (3) Niemand sollte andere maßregeln, ein bestimmtes Format in den unterschiedlichen Headern einzuhalten, wenn er nicht die zum Filtern gedachten Header verwendet. Sucht doch mal im Archiv: Dieses Thema ist jetzt bald so alt wie die Liste selber. .eot Sascha -- sa at programmers-world dot com http://www.livingit.de Boomarks online: http://www.mobile-bookmarks.info Soon available in english Mail geschrieben: Sonntag, den 06. Juli 2003 um 18:55

On Sat, Jul 05, 2003 at 08:23:23PM +0200, Martin Mewes wrote:

Am Samstag, 5. Juli 2003 18:47 schrieb Sven Schupp :

...

SELECT * FROM XXX WHERE keyword LIKE "%YYY%";

Hat geholfen, danke :-)

Das performt allerdings wie Scheiße. MySQL sucht in einer Tabelle mit einem Index, wenn ein solcher für diese Spalte existiert und es ihn verwenden kann und die Verwendung des Index dem Optimizier opportun erscheint. Ein Index auf einer Tabellenspalte existiert, wenn die Spalte PRIMARY KEY ist, oder wenn man den Index manuell auf einer Spalte, die nicht PRIMARY KEY ist, angelegt hat. Man kann auch einen Index auf eine PRIMARY KEY Spalte legen, aber das ist nutzloser Overhead. alter table t add unique ( s ); alter table t add index ( s ); Das erste Statement legt einen Index mit einer UNIQUE Constraint auf t.s, das zweite Statement legt einen Index ohne eine solche Constraint auf t.s. Die erste Variante ist marginal schneller. Ob man Variante eins oder zwei verwendet, hat keine Performancegründe, sondern Gründe in der Datenbanklogik. Ein Index für eine Spaltensuche kann verwendet werden, wenn die Spalte in der Query frei steht, und wenn die Vergleichsoperation vom Index profizieren könnte. select * from t where s+0 = 10; Diese Query kann nicht vom Index profizieren, da s+0 ein Ausdruck ist (mit dem Ziel, s varchar(20) in ein Integer umzuwasndeln) und die Spalte nicht frei steht. select * from t where substr(s, 10, 4) = "2003"; Auch hier steht s in einem Ausdruck. select * from t where s-now < 10*86400; Auch hier steht s in einem Ausdruck. Formt man den Ausdruck um zu select * from t where s < 10*86400+now; und damit zu korrektem SQL a la select * from t where s < date_add(now, 10 days); steht s frei und der Index kann verwendet werden. Auch Stringsuchen können beschleunigt werden, jedenfalls für das fixe Prefix eines LIKE-Vergleiches: select * from t where s like "prefix%postfix"; Hier kann der Index immerhin verwendet werden, um die Suche auf alle s einzuschränken, die "prefix" als Prefix haben. Eine Suche a la select * from t where s like "%substring%"; ist immer ein Full Table Walk. Ein Index, der verwendet werden kann, wird verwendet, wenn es dem Optimizer opportun erscheint. Der Optimizer wird für sehr kleine Tabellen (die ganze Tabelle paßt in einen Block) niemals einen Index verwendet. Stattdessen sieht er die Tabelle als constant table an, und hält einfach die gesamte Tabelle im Speicher. Er wird auch niemals einen Index verwenden, wenn die Kardinalität der Spalte zu klein ist. Einen Index auf geschlecht enum("m", "f", "?") zu legen bringt nix: Bei angenommener Gleichverteilung sind in jedem Block sowohl Datensätze mit geschlecht='m' und geschlecht='f'. In diesem Fall würde eine Suche im Index das Laden des Index plus das Laden aller Datenblöcke notwendig machen, und das ist langsamer als ein Full Table Walk, der das Laden aller Datenblöcke notwendig macht. Der Optimizer entscheidet diese Dinge auf der Basis der Histogrammdaten der Tabellenspalte, und diese werden mit "optimize table" und "analyze table" gepflegt. Es ist also lohnend, regelmäßig einmal in der Nacht oder wenigstens alle paar Wochen ein entsprechendes Kommando auf alle Tabellen abzufahren. Ob und wie der Optimizer die Welt sieht, kann man mit einem "explain select ..." leicht feststellen. Der entsprechende Abschnitt im Handbuch von MySQL ist Pflichtlektüre.

my $sth = $dbh->prepare( "SELECT * FROM Searchbase WHERE Description LIKE \"\%$suche\%\""

In Deinem Fall deutet diese Query auf eine nicht normalisierte Darstellung der Werte hin (falls Description die Form "a, b, c, ..." hat, ist es eine nicht normalisierte n:m Beziehung, die vorliegt) oder auf eine nicht normalisierbare Darstellung (wenn Description ein Volltextfeld ist). Im ersten Fall sollte eine Tabelle t_ext angelegt werden, in die die a, b und c eingetragen werden und es sollte eine Relationstabelle t_rel angelegt, in der Paare von t_id und t_ext_id eingetragen werden. Im zweiten Fall sollte stattdessen ein MySQL FULLTEXT INDEX verwendet werden, und die Abfrage sollte mit MATCH AGAINST() gemacht werden. Dies ist viel schneller als ein LIKE "%x%" und der Gewinn ist um so größer, je mehr Daten vorliegen. Kristian

Hallo Harald, Am Samstag, 5. Juli 2003 20:10 schrieb Harald Land :

select SPALTENAME from TABELLENNAME where SPALTENNAME like '%SUCHWORT%';

Funzt jedoch nicht ... :-(

Im übrigen ist es besser zu de.comp.datenbanken.misc posten.

Da hast Du sicherlich recht und eigentlich würde ich das auch tun, aber "auf die Schnelle" mußte halt die SuSE-Liste herhalten, weil für eine kurze Frage extra eine neue NG zu suagen, sich dort durch die FAQ zu lesen und dann doch die Frage zu stellen erschien mir hier bei einer Hirnblockade doch ein wenig mehr Aufwand als nötig. Trotzdem hast Du recht und ich gelobe Besserung.

select SPALTENAME from TABELLENNAME where SPALTENNAME in ('%KEYWORD1%','%KEYWORD2%')

Danke auch für diesen Hinweis. Kann ich sicherlich gut gebrauchen. kind regards Martin Mewes -- http://www.mamemu.de/ | Heimatseite :-) http://vmware.itst.org/ | Ein deutschsprachiges VMware-Forum http://vmware.mamemu.de/faq/ | VMWare-Dokumentations-Projekt :-) Key exported to: | pgp.mit.edu:11371 via WWW-Interface

Moin, Am Sam, 2003-07-05 um 20.51 schrieb Martin Mewes:

für eine kurze Frage extra eine neue NG zu suagen, sich dort durch die FAQ zu lesen und dann doch die Frage zu stellen erschien mir hier bei einer Hirnblockade doch ein wenig mehr Aufwand als nötig.

Tip: Bei Google kann man Newsgroups nicht nur durchsuchen, sondern auch über Webinterface schreiben. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Hallo Jan, Am Samstag, 5. Juli 2003 23:04 schrieb Jan.Trippler@t-online.de (Jan Trippler): [select *]

Sauber ist das schon, es ist nämlich im ANSI definiert. Es ist nur meist langsamer (der Server muss erst die Tabellenstruktur ermitteln) und wenig portabel. Im Allgemeinen geht man nämlich in einer Anwendung spaltenweise durch jeden gefundenen Satz und macht irgendas damit. Wenn nun die Tabellenstruktur geändert wird (z. B. eine Spalte neu hinzukommt), stimmt die Anzahl der gelieferten Spalten nicht mehr mit der Anzahl der in der Anwendung erwarteten Felder überein und das kann zu Fehlern führen.

Was aber nur dann ein Problem ist, wenn man eine Spalte "dazwischen" schiebt. Hängt man die Spalte jedoch "hintendran", dann sollte das gehen. Ist in meinem Fall jedoch nicht erforderlich (noch nicht). Danke für alle Antworten :-) kind regards Martin Mewes -- http://www.mamemu.de/ | Heimatseite :-) http://vmware.itst.org/ | Ein deutschsprachiges VMware-Forum http://vmware.mamemu.de/faq/ | VMWare-Dokumentations-Projekt :-) Key exported to: | pgp.mit.edu:11371 via WWW-Interface

Am Sonntag, 6. Juli 2003 12:09 schrieb Martin Mewes:

Was aber nur dann ein Problem ist, wenn man eine Spalte "dazwischen" schiebt. Hängt man die Spalte jedoch "hintendran", dann sollte das gehen. Ist in meinem Fall jedoch nicht erforderlich (noch nicht).

In jedem Fall werden mehr Daten übertragen, als notwendig, was bei Abfragen übers Netzwerk unnötige Bandbreite und je nach Verarbeitung Performance und Speicher kosten kann. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

On Mon, 07 Jul 2003 at 10:03 (+0200), Kristian Koehntopp wrote:

On Sat, Jul 05, 2003 at 11:04:35PM +0200, Jan Trippler wrote:

...

...

select SPALTENAME from TABELLENNAME where upper(SPALTENNAME) like upper('%SUCHWORT%';) ^^ typo?

Nein, das ist nicht besser, das ist was anderes. Dieser select führt eine case-insensitive Suche durch, der andere nicht.

In MySQL wird ein varchar case-insensitive vergleichen, es sei denn,

- der varchar wurde mit dem Attribut binary deklariert oder - der Vergleich wurde im im SELECT Statement mit dem Attribut binary deklariert.

Ja, das hatte ich in meiner Mail weiter unten ja auch geschrieben. Aber trotzdem sind die selects ohne / mit UPPER() unterschiedlich. Denn der o. g. select sucht auch in einer mit binary deklarierten Tabellenspalte case-insensitiv. Auf diesen Unterschied wollte ich hinweisen.

Das o.a. Statement ist in jedem Fall langsam. Selbst wenn kein LIKE "%x%" verwendet werden würde, steht SPALTENNAME in einem Funktionsaufruf, und da MySQL anders als Oracle ab Version 8 keine Indices auf Funktionsresultaten anlegen kann, würde selbst für ein UPPER(SPALTENNAME) = 'SUCHWORT' kein Index verwendet werden. Dieses Konstrukt will man also unbedingt vermeiden. [...]

ACK, aber manchmal hat man als Anwendungsentwickler keinen Einfluss auf das DB-Design und dann muss man mit dem leben, was man vorgesetzt kriegt (z. B. bei zugekauften Datenbanken - Stichwort Deutsche Post). Man kann zwar in einigen Fällen solche Datenbanken in ein eigenes, passenderes DB-Modell importieren, aber zum Teil verbieten die Lizenzbedingungen oder die Update-Häufigkeit sowas. Jan

On Mon, 07 Jul 2003 at 14:15 (+0200), Kristian Koehntopp wrote:

On Mon, Jul 07, 2003 at 01:14:57PM +0200, Jan Trippler wrote:

...

ACK, aber manchmal hat man als Anwendungsentwickler keinen Einfluss auf das DB-Design und dann muss man mit dem leben, was man vorgesetzt kriegt (z. B. bei zugekauften Datenbanken - Stichwort Deutsche Post).

Die Datenbank der Deutschen Post ist Schrott, dessen Design aus den 1970ern stammt und muß durch einen passenden Importer erst einmal normalisiert werden. Ich habe das mit den Azubis hier (http://www.netuse.de) im Rahmen unserer Datenbankausbildung einmal als Beispielprojekt durchgezogen. Die Performancevergleiche vorher/nachher waren sehr instruktiv für die - jetzt wissen sie auch, was Logarithmen sind.

Deshalb war mir das Beispiel in Erinnerung ;-) Ich habe das auch schon hinter mir, weiss aber nicht genau, ob das damals so richtig legal war (irgendwie habe ich noch im Hinterkopf, dass Auszüge aus der DB wohl nicht gestattet waren, kann mich aber auch irren - ist schon einige Jahre her). Jan