[MySQL] Twee kolommen samenvoegen en gebruiken in WHERE*

[r0b]

Hi,

Ik zit hier al een goede middag me op blind te staren, maar ik kom er niet op.

Situatie:
Ik heb 2 tables; products_attributes en products_stock. Met een al bestaande SELECT wordt alles uitgelezen.
Wat ik wil is een extra WHERE-clause toevoegen waar hij products_attributes.options_id en products_attributes.options_values_id vergelijkt tegen products_stock_attributes.
Probleem is, dat in products_attributes deze data in 2 kolommen staat en in products_stock in 1.

products_attributes

products_attributes_id	products_id	options_id	options_values_id
1	1	4	1
2	1	4	3

products_stock

products_stock_id	products_id	products_stock_attributes	products_stock_quantity
1	1	4-1	4
2	1	4-3	16

Ik zal dus options_id en options_values_id moeten samenvoegen met een streepje ertussen voordat ik hem kan vergelijken tegen products_stock_attributes.

Ik heb me suf gezocht op "samenvoegen kolommen", het geprobeerd met concat_ws (onmogelijk?, ik wil mijn huidige select houden), maar kom er niet uit. Is wat ik wil überhaupt wel mogelijk

[ Voor 5% gewijzigd door r0b op 29-07-2009 14:53 ]

[Exception]

Als ik het goed begrijp wil jij "joinen". Voorbeeldje

Snelle tip: Download Navicat. Hiermee kun je makkelijk meerdere tabellen aan elkaar koppelen (joinen) door lijntjes te trekken. Tevens biedt het programma nog veel meer handige mogelijkheden (Vergelijkbaar met PhpMyAdmin).

[ Voor 65% gewijzigd door Exception op 29-07-2009 14:56 ]

[r0b]

Exception schreef op woensdag 29 juli 2009 @ 14:54:
Als ik het goed begrijp wil jij "joinen". Voorbeeldje

Snelle tip: Download Navicat. Hiermee kun je makkelijk meerdere tabellen aan elkaar koppelen (joinen) door lijntjes te trekken. Tevens biedt het programma nog veel meer handige mogelijkheden (Vergelijkbaar met PhpMyAdmin).

Hmm, maar ik wil de data uit 2 kolommen vergelijken tegen data in 1 kolom, dat lijkt me wat anders dan joinen (wat ik al gebruik voor andere zaken)?

[Wolfboy]

Waarschijnlijk heb je wel wat aan dit gedeelte van de FAQ: Programming FAQ - SQL

Oeps, te snel gelezen.

Iets opslaan als "4-1" is een _heel_ slecht idee en zou ik dus proberen te verhelpen in plaats van het op te lossen op deze manier, maar als het toch moet dan kan je zoiets doen

SQL:

SELECT ... WHERE products_stock_attributes = CONCAT(options_id, '-', options_values_id)

[ Voor 58% gewijzigd door Wolfboy op 29-07-2009 15:00 ]

[r0b]

Wolfboy schreef op woensdag 29 juli 2009 @ 14:58:
Waarschijnlijk heb je wel wat aan dit gedeelte van de FAQ: Programming FAQ - SQL

Oeps, te snel gelezen.

Iets opslaan als "4-1" is een _heel_ slecht idee en zou ik dus proberen te verhelpen in plaats van het op te lossen op deze manier

osCommerce. Nouja.. een modificatie uit 2003 .. gelukkig niet mijn systeem.

maar als het toch moet dan kan je zoiets doen

SQL:

SELECT ... WHERE products_stock_attributes = CONCAT(options_id, '-', options_values_id)

Ik had CONCAT_WS al gebruikt maar dacht dat je deze alleen in de SELECT kon gebruiken, niet achteraf in de WHERE-clause ... ik ga er eens mee stoeien.

[ Voor 17% gewijzigd door r0b op 29-07-2009 15:10 ]

[cariolive23]

Offtopic:

niet achteraf in de WHERE-clause

Vooraf zul je bedoelen, de WHERE wordt eerst uitgevoerd en daarna pas de SELECT. De database moet eerst weten welke records er moeten worden opgevraagd.

De volgende query zal ook keurig mislukken:

SQL:

SELECT a AS b FROM tabel WHERE b = 1;

De alias b bestaat niet in de WHERE, deze alias wordt pas later aangemaakt.

[plagvreugd]

Je kan de concat-functie, net als alle functies, inderdaad overal in de query gebruiken, dus niet alleen in de SELECT.

Volgens mij heb je hem hier trouwens niet per se nodig in een WHERE, maar 'mooier' is m.i.in de join-conditie:

SELECT ...
FROM products_attributes
LEFT JOIN products_stock
ON CONCAT(options_id, '-', options_values_id) = products_stock.products_stock_attributes
WHERE ... <eventuele andere clausules>

[Voutloos]

Dat verschilt qua gedrag, dus taakje voor ts om te bedenken welk gedrag hij wil.

[plagvreugd]

Voutje mijnerzijds: maak er een INNER join van en het gedrag is hetzelfde als joinen + een WHERE-clause, toch?

( kan het mis hebben want heb vooral Oracle-SQL-ervaring, niet zozeer MySQL. En ook zonder die want, ik kan het mishebben, punt.)

[GlowMouse]

Zet die ene kolom om in twee kolommen als je nog een beetje gebruik wilt maken van indexen (of je moet die stock_attributes in je query alsnog uit elkaar trekken).

[Wolfboy]

plagvreugd schreef op woensdag 29 juli 2009 @ 16:36:
Voutje mijnerzijds: maak er een INNER join van en het gedrag is hetzelfde als joinen + een WHERE-clause, toch?

( kan het mis hebben want heb vooral Oracle-SQL-ervaring, niet zozeer MySQL. En ook zonder die want, ik kan het mishebben, punt.)

Helemaal correct, dat is gewoon vastgelegt in de SQL standaard.

GlowMouse schreef op woensdag 29 juli 2009 @ 22:12:
Zet die ene kolom om in twee kolommen als je nog een beetje gebruik wilt maken van indexen (of je moet die stock_attributes in je query alsnog uit elkaar trekken).

Dat gaat dus niet, het is een bestaand osCommerce systeem dat het veroorzaakt... kan hij weinig aan veranderen lijkt me

[plagvreugd]

Dat gaat dus niet, ...

Het gedeelte tussen haakjesuit GlowMouses post, het uit elkaar trekken van die stock_attributes in de query, is natuurlijk nog wel een aardige optie, dan kan TS iig nog indexen op de tabel products_attributes gebruiken (want net als GlowMouse vermoed ik dat deze met de concat niet gebruikt worden).

Iets als

SQL:

SELECT ...
FROM products_attributes
LEFT JOIN products_stock
ON options_id = substr(products_stock_attributes, 1, instr(products_stock_attributes, '-')-1)
AND options_values_id = substr(products_stock_attributes, instr(products_stock_attributes, '-')+1, length(products_stock_attributes))
WHERE ... <eventuele andere clausules>

[Voutloos]

Je verruilt de ene string functie waarbij je geen index kan gebruiken voor een ander.

offtopic:
Zonder de inhoud van de kolommen te verandeen is "LIKE '".$options_id."-%'" je enige kans op een gedeeltelijke index, maar dat werkt dus ook enkel als je enkel bepaalde rows zoekt.

[ Voor 54% gewijzigd door Voutloos op 30-07-2009 22:03 ]

[Wolfboy]

idd. Voutloos. Al kan het nog steeds een voordeel opleveren hoor, het hangt er maar net vanaf welke van de tabellen groter is.

Bij een grote products_stock tabel zou de methode van plagvreugd sneller zijn, bij een grote products_attributes zou mijn methode sneller zijn.

[GlowMouse]

Wolfboy schreef op donderdag 30 juli 2009 @ 22:12:
idd. Voutloos. Al kan het nog steeds een voordeel opleveren hoor, het hangt er maar net vanaf welke van de tabellen groter is.

Bij een grote products_stock tabel zou de methode van plagvreugd sneller zijn, bij een grote products_attributes zou mijn methode sneller zijn.

Bij een inner join joint MySQL alles op de eerste tabel. De query van plagvreugd is dus veel beter indexeerbaar middels een index op producs_stock.(options_id,options_values_id)

[Wolfboy]

GlowMouse schreef op vrijdag 31 juli 2009 @ 01:04:
[...]

Bij een inner join joint MySQL alles op de eerste tabel. De query van plagvreugd is dus veel beter indexeerbaar middels een index op producs_stock.(options_id,options_values_id)

En mijn versie is prima indexeerbaar als er een index op products_stock_attributes zit, dan moet de database elke rij in products_stock omzetten naar een string met de concat functie, waarna de index gebruikt kan worden voor de lookups. Bij weinig products_stock rijen is dat dus de betere optie.

Bij een inner join is het namelijk totaal irrelevant of je eerder tabel A of eerder tabel B pakt

[Verwijderd]

Samenvoegen = union, ergo http://dev.mysql.com/doc/refman/5.0/en/union.html
Have fun.

[Manuel]

Verwijderd schreef op vrijdag 31 juli 2009 @ 07:41:
Samenvoegen = union, ergo http://dev.mysql.com/doc/refman/5.0/en/union.html
Have fun.

Zeg er dan ook even bij dat het dezelfde kolom aantal moet hebben

@TS:
Als ik jou was zou ik gewoon voor de JOIN gaan en een groot gedeelte aan het osCommerce aanpassen (of wachten op de nieuwe versie waar ze nog mee bezig zijn ).

[Voutloos]

GlowMouse schreef op vrijdag 31 juli 2009 @ 01:04:
[...]

Bij een inner join joint MySQL alles op de eerste tabel. De query van plagvreugd is dus veel beter indexeerbaar middels een index op producs_stock.(options_id,options_values_id)

Omgekeerde logica. Stel je eens voor hoe je de 2e tabel erbij moet joinen. Hoe vind je de rows? Juist middels een povere string functie...

Anyway, dit gaat nergens over zonder stats over het aantal rows. En ts kan gewoon dmv explain de beste strategie kiezen.

[ Voor 12% gewijzigd door Voutloos op 31-07-2009 09:16 ]

[plagvreugd]

Verwijderd schreef op vrijdag 31 juli 2009 @ 07:41:
Samenvoegen = union, ergo http://dev.mysql.com/doc/refman/5.0/en/union.html
Have fun.

Ik zie niet in dat union hier nut heeft. TS heeft t over kolommen per record samenvoegen, geen queryresultaten (dus recordsets).

[GlowMouse]

Jullie hebben gelijk, ik dacht dat alles gejoind werd op die tabel met die 3-1 kolom.

[r0b]

Bedankt allemaal voor het meedenken; ik ga er morgen nog even voor zitten adhv jullie suggesties.

Het betreft overigens een bestaand osCommerce systeem wat niet onder mijn beheer valt; wij hebben alleen een script dat er gegevens uit plukt. De db aanpassen is dus een nogo. En een LIKE zal in dit geval helaas ook niet werken.