Re: Problem bei MySQL-Abfrage

Martin Nadoll wrote:

> ich frage aus einer MySQL Tabelle mittels PHP Datensätze ab:

Datenbankfragen gehören in die DB-Gruppe!
Ich hab nen FUP dahin (de.comp.lang.php.datenbanken) gesetzt.

> WHERE name > ''

Ich bevorzuge WHERE name <> ''

> AND (personenart = 'dlaf' OR personenart LIKE '%dlem%')

Welchen Grund hat das LIKE hier? Sollte nicht folgendes reichen:

AND (personenart = 'dlaf' OR personenart = 'dlem')

LIKE drückt die Performance

> AND aktiv = 'j'";


> Es gibt in der Tabelle (die momentan mit 15 Datensätzen noch sehr
> übersichtlich ist) 3 Datensätze, die gefunden werden müssten:
> einmal ist personenart 'dlaf' und dieser Datensatz wird gefunden
> 2 Personen haben die personenart 'dlem' aber diese werden nicht gefunden.
> mysql_num_rows ($count) ist 1.

Ich habs mal nachgebaut, da Du dich über den Aufbau Deiner Tabelle
ausschweigst:

CREATE TABLE myTbl (
id INT(7) NOT NULL AUTO_INCREMENT,
name VARCHAR(24) NOT NULL DEFAULT '',
personenart SET('dlaf','dlem','dlim') DEFAULT 'dlaf',
aktiv SET('j','n'),
PRIMARY KEY (id)
);
INSERT INTO myTbl VALUES(null,'Max',DEFAULT,'j');
INSERT INTO myTbl VALUES(null,'Maxi',DEFAULT,'n');
INSERT INTO myTbl VALUES(null,'Fritz','dlem','j');
INSERT INTO myTbl VALUES(null,'Fritzi','dlem','n');
INSERT INTO myTbl VALUES(null,'Anna','dlim','j');
INSERT INTO myTbl VALUES(null,'Anni','dlim','n');
INSERT INTO myTbl VALUES(null,'',DEFAULT,'j');
INSERT INTO myTbl VALUES(null,'',DEFAULT,'n');

SELECT DISTRICT name FROM myTbl
WHERE name <> ''
AND (personenart='dlaf' OR personenart='dlem')
AND aktiv = 'j';

Funktioniert wunderbar. In PHP wie in Mysql direkt.

PHP-Version? MySql-Version? Tabellenaufbau?

MfG, Ulf

Re: Problem bei MySQL-Abfrage

So, jetzt erlaube ich mir noch ein paar Korrekturen ;-):

Ulf Kadner schrieb:

>> WHERE name > ''
>
> Ich bevorzuge WHERE name <> ''

Ich bevorzuge WHERE name IS NOT NULL. Das drückt IMHO besser aus: Name
nicht bekannt. Weil einen Namen, der aus einem Leerstring besteht, gibts
glaub ich nicht.

> CREATE TABLE myTbl (
> id INT(7) NOT NULL AUTO_INCREMENT,
> name VARCHAR(24) NOT NULL DEFAULT '',

Siehe oben.

> personenart SET('dlaf','dlem','dlim') DEFAULT 'dlaf',
> aktiv SET('j','n'),

Du mögest doch bitte noch einmal nachdenken, ob SET wirklich der
geeignete Datentyp für diese beiden Felder ist ;-). Bzw. ob deine
Abfrage dann überhaupt Ergebnisse bringt.

INSERT INTO myTbl VALUES(null,'Hans','dlaf,dlem','j,n');

SELECT DISTINCT name FROM myTbl
WHERE name <> ''
AND (personenart='dlaf' OR personenart='dlem')
AND aktiv = 'j';



Für aktiv wäre IMHO immer noch BOOLEAN optimal. Außer man führt so einen
"femininen" boolschen Datentyp ein: ja, nein, vielleicht ;-).

gruss, heli

Re: Problem bei MySQL-Abfrage

Helmut Chang wrote:

> Ich bevorzuge WHERE name IS NOT NULL. Das drückt IMHO besser aus: Name
> nicht bekannt. Weil einen Namen, der aus einem Leerstring besteht, gibts
> glaub ich nicht.

Bei OP schon. Ich bin nur auf Seine Daten eingegangen

>> aktiv SET('j','n'),
> Du mögest doch bitte noch einmal nachdenken, ob SET wirklich der
> geeignete Datentyp für diese beiden Felder ist ;-).

Hallo? Was soll das? Die Struktur der Tabelle scheint hier vom OP so
genutzt zu werden. TINYINT(1) ist zu bevorzugen, logisch. Aber damit
kann ich nicht das nachbilden was der OP hat. Habe ich genau dazu extra
erwähnt.

> Für aktiv wäre IMHO immer noch BOOLEAN optimal.

Das kannst Du so nicht sagen, da Du nicht weist ob der OP bloss ne 3.x
Version nutzt.

MfG, Ulf

Re: Problem bei MySQL-Abfrage

Helmut Chang wrote:

> Ich bevorzuge WHERE name IS NOT NULL. Das drückt IMHO besser aus: Name
> nicht bekannt. Weil einen Namen, der aus einem Leerstring besteht, gibts
> glaub ich nicht.

Selbstverständlich gibt es den leeren String '' und selbstverständlich
ist der nicht NULL.
(Okay es gibt eine Reihe kranke Implementationen da drausen, für die
NULL = '' gilt. z.b. Orakel)

Wenn ein Name unbekannt ist sollte allerding die Spalte mit NULL
belegt sein.

CIAO
andreas
--
.... oben geht es um den Thron - unten geht es um Deinen Hintern ...
[Keimzeit]
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de

Re: Problem bei MySQL-Abfrage

Ulf Kadner schrieb:

> Helmut Chang wrote:
>
>>> aktiv SET('j','n'),
>>
>> Du mögest doch bitte noch einmal nachdenken, ob SET wirklich der
>> geeignete Datentyp für diese beiden Felder ist ;-).
>
> Hallo? Was soll das? Die Struktur der Tabelle scheint hier vom OP so
> genutzt zu werden. TINYINT(1) ist zu bevorzugen, logisch. Aber damit
> kann ich nicht das nachbilden was der OP hat. Habe ich genau dazu extra
> erwähnt.

Du willst also wirklich zulassen, dass `aktiv` _beide_ Werte in _einer_
Zeile annehmen kann? Wohl kaum.

>> Für aktiv wäre IMHO immer noch BOOLEAN optimal.

Wobei BOOLEAN nichts anderes ist als TINYINT(1). Noch weniger Speicher
(nämlich nur 1 Bit) belegt CHAR(0) NULL, falls sich Dein "optimal" auf
den Speicherverbrauch bezieht :-)

> Das kannst Du so nicht sagen, da Du nicht weist ob der OP bloss ne 3.x
> Version nutzt.

Richtig. Trotzdem dürfte SET der falcshe Datentyp sein. ENUM wäre da
schon wesentlich besser.

Gruß. Claus

Re: Problem bei MySQL-Abfrage

Claus Reibenstein wrote:

> Richtig. Trotzdem dürfte SET der falcshe Datentyp sein. ENUM wäre da
> schon wesentlich besser.

Falsch ja, da gebe ich DIr recht.

MfG, Ulf

Re: Problem bei MySQL-Abfrage

Ulf Kadner schrieb:

>>> aktiv SET('j','n'),
>> Du mögest doch bitte noch einmal nachdenken, ob SET wirklich der
>> geeignete Datentyp für diese beiden Felder ist ;-).
^^^^^^
>
> Hallo? Was soll das? Die Struktur der Tabelle scheint hier vom OP so
> genutzt zu werden. TINYINT(1) ist zu bevorzugen, logisch. Aber damit
> kann ich nicht das nachbilden was der OP hat. Habe ich genau dazu extra
> erwähnt.

Ich sprach von beiden Feldern. Ich hab dir ein Beispiel gegeben, wo das,
was du gepostet hast, nicht funktioniert. Ich hab dir den Link zur Doku
genannt. Dass du SET und ENUM bei aktiv verwechselt hast, hast du eh
schon gemerkt.

Bei personenart könnte es durchaus sinnvoll sein, SET zu verwenden. Das
wissen wir nicht. Nur funktioniert dann dein vorgschlagener SELECT
nicht, sondern man muss eben wieder genau auf bspw. LIKE ausweichen, wie
der OP hatte.

>> Für aktiv wäre IMHO immer noch BOOLEAN optimal.

> Das kannst Du so nicht sagen, da Du nicht weist ob der OP bloss ne 3.x
> Version nutzt.

Dann halt BOOL ;-). Das gabs mindestens schon in 3.23.

gruss, heli

Re: Problem bei MySQL-Abfrage

Andreas Froede schrieb:

>> Ich bevorzuge WHERE name IS NOT NULL. Das drückt IMHO besser aus: Name
>> nicht bekannt. Weil einen Namen, der aus einem Leerstring besteht, gibts
>> glaub ich nicht.
>
> Selbstverständlich gibt es den leeren String '' und selbstverständlich
> ist der nicht NULL.

Genau das hab ich doch gesagt.

gruss, heli

Re: Problem bei MySQL-Abfrage

Helmut Chang wrote:

> Ulf Kadner schrieb:
>> Das kannst Du so nicht sagen, da Du nicht weist ob der OP bloss ne 3.x
>> Version nutzt.
>
> Dann halt BOOL ;-). Das gabs mindestens schon in 3.23.

Ist das nicht auch bloss ein Pseudonym für TINYINT(1)? Mir war doch so. :-x

MfG, Ulf

Re: Problem bei MySQL-Abfrage

Ulf Kadner schrieb:
> Helmut Chang wrote:
>> Ulf Kadner schrieb:
>>> Das kannst Du so nicht sagen, da Du nicht weist ob der OP bloss ne
>>> 3.x Version nutzt.

>> Dann halt BOOL ;-). Das gabs mindestens schon in 3.23.

> Ist das nicht auch bloss ein Pseudonym für TINYINT(1)? Mir war doch so. :-x

Es ist ein Synonym für TINYINT(1), kein Pseudonym :).

Re: Problem bei MySQL-Abfrage

Helmut Chang wrote:
> Andreas Froede schrieb:
>
> >> Ich bevorzuge WHERE name IS NOT NULL. Das drückt IMHO besser aus: Name
> >> nicht bekannt. Weil einen Namen, der aus einem Leerstring besteht, gibts
> >> glaub ich nicht.
> >
> > Selbstverständlich gibt es den leeren String '' und selbstverständlich
> > ist der nicht NULL.
>
> Genau das hab ich doch gesagt.

Sorry, ich hatte in deinem Text das "Namen" als "String" gelesen.
Und außerdem hatte ich gestern eine "Anwendung" auf dem Tisch bei der
der Produzent genau '' <> NULL und NULL <> NULL absolut nicht kapiert
hat.

CIAO
andreas
--
.... oben geht es um den Thron - unten geht es um Deinen Hintern ...
[Keimzeit]
Klettern in Thüringen: http://www.climb.spider-net.de
Kletterhalle in Jena: http://www.wand.spider-net.de