Komplizierte Abfrage

Komplizierte Abfrage

am 11.09.2007 18:46:31 von Marcel Polty

Hallo,

ich stosse mit der Erweiterung des folgenden Queries an meine Grenzen.

So wie es unten dargestellt wird funktioniert es.
Nun sollen aber die Lagerbestände aus
"testdb.rs_test2.lager" und
"testdb.rs_test3.lager" und eventuell
"testdb.rs_test4.lager" und eventuell
"testdb.rs_test5.lager" zu
"testdb.rs_test.lager" addiert werden.

Das funktionierende Select:

select distinct
testdb.rs_test.id,
testdb.rs_test.breite,
testdb.rs_test.bild,
testdb.rs_test.hersteller,
testdb.rs_test.lager,
testdb.rs_test.vk_preis,
testdb.rs_preis_calc.von_preis,
testdb.rs_preis_calc.bis_preis,
testdb.rs_preis_calc.euro_aufschlag,
testdb.rs_preis_calc.proz_aufschlag,
GREATEST(if (euro_aufschlag>0 and vk_preis > 0 , (vk_preis*1) +
euro_aufschlag, 0),
if (proz_aufschlag>0,
(vk_preis*1)+(vk_preis*(proz_aufschlag/100)), 0),vk_preis) AS akpreis,
GREATEST(if (euro_aufschlag>0 , (vk_preis*1) + euro_aufschlag, 0),
if (proz_aufschlag>0,
(vk_preis*1)+(vk_preis*(proz_aufschlag/100)), 0),vk_preis) AS vkpreis
from testdb.rs_test, testdb.rs_preis_calc
where ((vk_preis > von_preis) and (vk_preis <= bis_preis)
and (99991 = testdb.rs_preis_calc.db_id) and
(0 = testdb.rs_preis_calc.preisgruppe))and
(testdb.rs_test.breite = '50') and
(testdb.rs_test.lang = '200') and
(testdb.rs_test.hersteller like 'Ikea%')

Über die ID kann ich die Datensätze selektieren. Aber wie baue ich das
in die where Klausel ein und wo addiere ich die Lagerbestände?

Kann mir jemand auf die Sprünge helfen?

Vielen Dank

Gruß Marcel

Re: Komplizierte Abfrage

am 12.09.2007 09:39:32 von Marcel Polty

Hallo,

ich habe es jetzt über "union" probiert:

>So wie es unten dargestellt wird funktioniert es.
>Nun sollen aber die Lagerbestände aus
>"testdb.rs_test2.lager" und
>"testdb.rs_test3.lager" und eventuell
>"testdb.rs_test4.lager" und eventuell
>"testdb.rs_test5.lager" zu
>"testdb.rs_test.lager" addiert werden.
>

(select distinct
testdb.rs_test.id,
testdb.rs_test.breite,
testdb.rs_test.bild,
testdb.rs_test.hersteller,
testdb.rs_test.lang,
testdb.rs_test.lager,
testdb.rs_test.vk_preis,
testdb.rs_preis_calc.von_preis,
testdb.rs_preis_calc.bis_preis,
testdb.rs_preis_calc.euro_aufschlag,
testdb.rs_preis_calc.proz_aufschlag,
testdb.rs_test2.id,
testdb.rs_test2.lager,
GREATEST(if (euro_aufschlag>0 and vk_preis > 0 , (vk_preis*1) +
euro_aufschlag, 0),
if (proz_aufschlag>0,
(vk_preis*1)+(vk_preis*(proz_aufschlag/100)), 0),vk_preis) AS akpreis,
GREATEST(if (euro_aufschlag>0 , (vk_preis*1) + euro_aufschlag, 0),
if (proz_aufschlag>0,
(vk_preis*1)+(vk_preis*(proz_aufschlag/100)), 0),vk_preis) AS vkpreis
from testdb.rs_test, testdb.rs_preis_calc
where ((vk_preis > von_preis) and (vk_preis <= bis_preis)
and (99991 = testdb.rs_preis_calc.db_id) and
(0 = testdb.rs_preis_calc.preisgruppe))and
(testdb.rs_test.breite = '50') and
(testdb.rs_test.lang = '200') and
(testdb.rs_test.hersteller like 'Ikea%')
)
UNION
(
testdb.rs_test.id,
testdb.rs_test.breite,
testdb.rs_test.bild,
testdb.rs_test.hersteller,
testdb.rs_test.lang,
testdb.rs_test.lager,
testdb.rs_test.vk_preis,
testdb.rs_preis_calc.von_preis,
testdb.rs_preis_calc.bis_preis,
testdb.rs_preis_calc.euro_aufschlag,
testdb.rs_preis_calc.proz_aufschlag,
testdb.rs_test2.id,
testdb.rs_test2.lager,
from testdb.rs_test1, testdb.rs_test2, testdb.rs_preis_calc
where (testdb.rs_test.id = testdb.rs_test2.id)
)

Wenn ich diese Abfrage in phpMyAdmin ausführe, dann bekomme ich die
Fehlermeldung:
#1222 - The used SELECT statements have a different number of columns

Woran kann das liegen, was habe ich falsch gemacht?

Bin für jeden Tipp dankbar!

Gruß Marcel

Re: Komplizierte Abfrage

am 12.09.2007 09:50:36 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
http://a-kretschmer.de/pict4592.jpg

Re: Komplizierte Abfrage

am 12.09.2007 09:58:51 von Marcel Polty

Hallo Andreas,

danke für den Hinweis!

Die Fehlermeldung habe ich auch so gedeutet, kann aber keinen
Unterschied finden.
Ok, kann sein das ich Tomaten auf den Augen habe, aber für mich sind
in beiden Selects die gleichen Spalten und beide Tabellen sind absolut
identisch nur vom Inhalt her unterschiedlich.

Wenn Du einen Unterschied siehst, dann stoße mich bitte mit der Nase
drauf, ich brauch das heute offensichtlich. :-)

Danke und Gruß

Marcel

Andreas Kretschmer schrieb:

>begin Marcel Polty schrieb:
>> Hallo,
>>
>> ich habe es jetzt über "union" probiert:
>
>> Fehlermeldung:
>> #1222 - The used SELECT statements have a different number of columns
>>
>> Woran kann das liegen, was habe ich falsch gemacht?
>
>Wer lesen kann, ist klar im Vorteil. Bei einem UNION müssen alle
>beteiligten Selects dieselbe Anzahl und Typ von Spalten liefern. Dies
>ist bei Dir nicht der Fall.
>
>
>end
>Andreas

Re: Komplizierte Abfrage

am 12.09.2007 10:12:28 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
http://a-kretschmer.de/pict4592.jpg

Re: Komplizierte Abfrage

am 12.09.2007 10:15:43 von Claus Reibenstein

Marcel Polty schrieb:

> (select distinct
> testdb.rs_test.id,
> [...]
> testdb.rs_test2.lager,
> GREATEST[...]
> )
> UNION
> (
> testdb.rs_test.id,
> [...]
> testdb.rs_test2.lager,
> from [...]
> )
>
> Wenn ich diese Abfrage in phpMyAdmin ausführe, dann bekomme ich die
> Fehlermeldung:
> #1222 - The used SELECT statements have a different number of columns

Was auch absolut korrekt ist: beide SELECTs stimmen nur bis
einschließlich testdb.rs_test2.lager überein. Das zweite SELECT endet
damit, das erste jedoch nicht.

Gruß. Claus

Re: Komplizierte Abfrage

am 12.09.2007 10:27:10 von Claus Reibenstein

Marcel Polty schrieb:

> (select distinct
> [...]
> )
> UNION
> (
> testdb.rs_test.id,
> [...]
>
> Wenn ich diese Abfrage in phpMyAdmin ausführe, dann bekomme ich die
> Fehlermeldung:
> #1222 - The used SELECT statements have a different number of columns

Wenn _ich_ diese Abfrage ausführe, bekomme ich _diese_ Fehlermeldung:

#1064 - You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'testdb.rs_test.id,
testdb.rs_test.breite,
testdb.rs_test.bild,
testdb.rs_t' at line 32

Gruß. Claus

Re: Komplizierte Abfrage

am 12.09.2007 12:05:38 von Marcel Polty

Hallo Claus,

danke für den Tipp!

Claus Reibenstein schrieb:

>Wenn _ich_ diese Abfrage ausführe, bekomme ich _diese_ Fehlermeldung:
>
>#1064 - You have an error in your SQL syntax; check the manual that
>corresponds to your MySQL server version for the right syntax to use
>near 'testdb.rs_test.id,
>testdb.rs_test.breite,
>testdb.rs_test.bild,
>testdb.rs_t' at line 32
>

OK, den Syntax Fehler habe ich beseitigt, die Fehlermeldung:
"#1222 - The used SELECT statements have a different number of
columns" bleibt aber.

Ich weiß das der Unterschied zwischen den beiden Selects in der
Greatest() Funktion liegt. Diese brauche ich aber in dem 2 Select
nicht. Was kann ich dann damit machen?

Ich dachte auch nicht das hier die Ursache der Fehlermeldung liegt,
weil ich ja alle in der Greates() Funktion verwendeten Felder in dem
2. Select auch verwendet habe.

Danke + Gruß

Marcel

Re: Komplizierte Abfrage

am 12.09.2007 12:10:50 von Andreas Kretschmer

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Komplizierte Abfrage

am 12.09.2007 15:06:05 von Harald Stowasser

Marcel Polty schrieb:
> Hallo,
>
> ich stosse mit der Erweiterung des folgenden Queries an meine Grenzen.
>
> So wie es unten dargestellt wird funktioniert es.
> Nun sollen aber die Lagerbestände aus
> "testdb.rs_test2.lager" und
> "testdb.rs_test3.lager" und eventuell
> "testdb.rs_test4.lager" und eventuell
> "testdb.rs_test5.lager" zu
> "testdb.rs_test.lager" addiert werden.

Btw, warum organisierst du gleiche Daten in unterschiedlichen Tabellen?

Re: Komplizierte Abfrage

am 12.09.2007 16:38:29 von Marcel Polty

Armer Andreas,

das Leben ist eine schlimme Belastung für dich, was?
Du solltest versuchen alles etwas lockerer zu sehen und dich nicht so
viel aufregen, das ist nicht gut für's Herz.
Einfach cool bleiben.

Grüße Marcel

Re: Komplizierte Abfrage

am 12.09.2007 17:21:07 von Marcel Polty

Hallo Harald,

Harald Stowasser schrieb:
>Btw, warum organisierst du gleiche Daten in unterschiedlichen Tabellen?

Es sind die gleichen Artikel von verschiedenen Quellen, mit
unterschiedlichen Lagerbeständen.

Gruß Marcel

Re: Komplizierte Abfrage

am 12.09.2007 17:31:47 von Sebastian Suchanek

Marcel Polty schrieb:
> Harald Stowasser schrieb:
>
>> Btw, warum organisierst du gleiche Daten in unterschiedlichen Tabellen?
>
> Es sind die gleichen Artikel von verschiedenen Quellen, mit
> unterschiedlichen Lagerbeständen.

Auch da erschiene es mir wesentlich geschickter, /eine/ Tabelle zu
verwenden und diese um eine weitere Spalte "Quelle" zu ergänzen.


Tschüs,

Sebastian

Re: Komplizierte Abfrage

am 12.09.2007 18:27:53 von Marcel Polty

Hallo Sebastian,

danke für die Anregung!

Sebastian Suchanek schrieb:
>
>Auch da erschiene es mir wesentlich geschickter, /eine/ Tabelle zu
>verwenden und diese um eine weitere Spalte "Quelle" zu ergänzen.
>
Mir wäre eine einzige Tabelle auch lieber, alleine von der
Geschwindigkeit her.
Es handelt sich aber um mehrere Shops. Alle greifen auf die gleichen
Grunddaten zu und jeder soll zusätzlich noch von eigenen Lieferanten
die Daten importieren können. Es können also unterschiedlich viele
Lieferanten sein. Bei den einen Shop ist es vielleicht nur ein
einziger Lieferant zusätzlich, bei einem anderen sind es vielleicht 5
Lieferanten.
Deshalb kann ich das nicht in eine einzige Tabelle zu packen.

Die andere Seite ist, das ich jetzt erst mal sehen muss wie das mit
der Geschwindigkeit wird. Ob das mit Union über mehrere Tabellen nicht
zu langsam wird.

Für Verbesserungs-Vorschläge bin ich jederzeit offen und dankbar.

Grüße Marcel

Re: Komplizierte Abfrage

am 12.09.2007 19:07:36 von Andreas Kretschmer

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Komplizierte Abfrage

am 12.09.2007 22:35:57 von Sebastian Suchanek

Marcel Polty schrieb:
> Hallo Sebastian,
>
> danke für die Anregung!
>
> Sebastian Suchanek schrieb:
>> Auch da erschiene es mir wesentlich geschickter, /eine/ Tabelle zu
>> verwenden und diese um eine weitere Spalte "Quelle" zu ergänzen.
>>
> Mir wäre eine einzige Tabelle auch lieber, alleine von der
> Geschwindigkeit her.
> Es handelt sich aber um mehrere Shops.

Dann wiederrum möchte ich aus Datenschutz- und Sicherheitsgründen
dringend dazu raten, die Daten der einzelnen Shops schön separat zu
halten. Selbstverständlich kombiniert mit einem sauberen Konzept für die
Zugriffsrechte innerhalb von MySQL.
Wozu dann allerdings Deine kombinierte Abfrage über mehrere Shops hinweg
gut sein soll, erschließt sich mir nicht so ganz.

> Alle greifen auf die gleichen
> Grunddaten zu und jeder soll zusätzlich noch von eigenen Lieferanten
> die Daten importieren können. Es können also unterschiedlich viele
> Lieferanten sein. Bei den einen Shop ist es vielleicht nur ein
> einziger Lieferant zusätzlich, bei einem anderen sind es vielleicht 5
> Lieferanten.
> Deshalb kann ich das nicht in eine einzige Tabelle zu packen.
> [...]

Abgesehen davon, daß ich Dein Problem immer noch nicht 100%ig verstanden
habe - hast Du Dir schon mal

http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29# F.C3.BCnfte_Normalform_.285NF.29


angesehen?


Tschüs,

Sebastian

Re: Komplizierte Abfrage

am 13.09.2007 12:22:00 von Marcel Polty

Hallo Sebastian,

Sebastian Suchanek schrieb:
>>> Auch da erschiene es mir wesentlich geschickter, /eine/ Tabelle zu
>>> verwenden und diese um eine weitere Spalte "Quelle" zu ergänzen.
>>>
>> Mir wäre eine einzige Tabelle auch lieber, alleine von der
>> Geschwindigkeit her.
>> Es handelt sich aber um mehrere Shops.
>
>Dann wiederrum möchte ich aus Datenschutz- und Sicherheitsgründen
>dringend dazu raten, die Daten der einzelnen Shops schön separat zu
>halten. Selbstverständlich kombiniert mit einem sauberen Konzept für die
>Zugriffsrechte innerhalb von MySQL.
>Wozu dann allerdings Deine kombinierte Abfrage über mehrere Shops hinweg
>gut sein soll, erschließt sich mir nicht so ganz.

Datenschutz ist kein Problem. Es hat niemand Zugriff auf die
Datenbank. Die Shopbetreiber kopieren die Daten jeder in ein seperates
FTP Verzeichnis und importiert wird über ein Script - Cronjob
gesteuert.

>> Alle greifen auf die gleichen
>> Grunddaten zu und jeder soll zusätzlich noch von eigenen Lieferanten
>> die Daten importieren können. Es können also unterschiedlich viele
>> Lieferanten sein. Bei den einen Shop ist es vielleicht nur ein
>> einziger Lieferant zusätzlich, bei einem anderen sind es vielleicht 5
>> Lieferanten.
>> Deshalb kann ich das nicht in eine einzige Tabelle zu packen.
>> [...]
>
>Abgesehen davon, daß ich Dein Problem immer noch nicht 100%ig verstanden
>habe - hast Du Dir schon mal

mmh... eigentlich gar nicht so kompliziert:
Eine Datenbank mit einem sehr umfangreichen und gepflegten
Artikelsortiment mit allen notwendigen Artikelinformationen, Bildern
usw. dient als Basisdatenbank für alle Shops.
Shopbetreiber A hat ein eigenes Lager und möchte diese Artikel auch in
seinem Shop anbieten. Er kann nun seinen Lagerbestand in eine separate
Datenbank importieren (über FTP / Script). Alle Artikel haben ein
einheitliches Nummernsystem über das man die Daten verknüpfen kann und
somit werden die Datenbestände aus seinem eigenen Lager dann auch in
seinem Shop angezeigt. In den anderen Shops natürlich nicht. Es könnte
auch sein, das ein Shop mehrere Läger hat oder aber noch Daten /
Lagerbestände von einem 2 oder 3. Großhändler bekommt. Und diese
sollen dann auch, nur in seinem Shop, angezeigt werden. OK?

>http://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29 #F.C3.BCnfte_Normalform_.285NF.29
Ich denke das die Normalisierung das sinnvollste wäre, habe aber ein
bisschen Bammel vor der Umsetzung.

Was macht das denn von der Geschwindigkeit aus ob ich mit UNION oder
über Normalisierung arbeite?

Danke + Gruß

Marcel