[SQL] probleem met verscheidene records combineren

[xshredx]

Ik heb een opdracht waarbij ik een database krijg van een bedrijf, en ik moet de gegevens daarin weergeven in enkele lijsten/rapporten.
Mijn probleem is dat deze database naar mijn insziens slecht gestructureerd is, en ik geen oplossing vind voor mijn probleem die niet:
- ofwel massa's queries nodig heeft
- ofwel een verandering in de structuur van de database behoeft, maar daar is dat bedrijf niet happig om.

Het betreft een tabel met daarin produkten.
De voor mijn probleem relevante produkt velden zijn:
produktmerk - produktnaam - produktformaat - produktprijs

Deze tabel is op deze manier opgevuld:

merk1 - produkt1 - formaat1 - 10
merk2 - produkt2 - formaat1 - 20
merk2 - produkt2 - formaat2 - 25
.
.

Merk op dat produkten als verschillende records opgeslagen zijn als hun formaat (en de bijhorende prijs) verschilt.

Nu wordt ik verondersteld om een lijst te genereren met bijvoorbeeld 100 produkten, waarvan ik moet weergeven: produktmerk - produktnaam en de formaten waarin het te krijgen is.

Ik bedoel dus:

code:

merk1 - produkt1
     formaat1 (10 euro)
merk2 - produkt2
     formaat1 (20 euro)
     formaat2 (25 euro)

De verschillende merk-produkt combinaties zoeken is geen probleem: gewoon een SELECT DISTINCT en ik heb alle produkten maar 1 keer, ongeacht of ze 1 keer of 5 keer in de tabel zitten met verschillende formaten.

Maar hoe kan ik zo handig mogelijk de verschillende formaten ophalen? Per produkt een query doen om te kijken welke formaten er aanwezig zijn? Dat betekent 100 extra queries als ik een lijst van 100 produkten moet weergeven...
Zie ik een elegante methode over het hoofd om toch te bereiken wat ik wil? M.a.w. zou een ietwat geavanceerdere query me toch de benodigde informatie kunnen opleveren?

Ik wil dus dat er van een situatie waarbij verschillende formaten van een item als afzonderlijke produkten in de database zitten (produktmerk en produktnaam zijn identiek), naar een situatie waarbij ze beschouwd worden als 1 produkt met zijn formaten.

Verdere technische info: de database in kwestie is mysql.

[dusty]

Oplossen met een simpel query met een group by, en dan netjes de opbouw van de "layout" naar de gebruiker daarin oplossen.

[jAnO!]

Volgens mij is hier de 'group by' functie voor uitgevonden. Succes..

edit:
en net te laat ... ;-)

[ Voor 30% gewijzigd door jAnO! op 14-10-2003 13:36 ]

[xshredx]

dusty schreef op 14 oktober 2003 @ 13:34:
Oplossen met een simpel query met een group by, en dan netjes de opbouw van de "layout" naar de gebruiker daarin oplossen.

Sorry, maar ik begrijp je nog niet helemaal.
Ik begrijp hoe een
SELECT produktmerk, produktnaam FROM tabel GROUP BY produktmerk, produktnaam;
hetzelfde zal opleveren als
SELECT DISTINCT produktmerk, produktnaam FROM tabel;

Maar ik dacht dat een group by enkel is als je aggregatie functies (sum, count, min, max, ...) wil gebruiken op een veld.
Kun je misschien een klein beetje meer uitleggen hoe jij de query dan ziet, en de verdere opbouw van de layout naar de gebruiker daarin oplost?

[dusty]

xshredx schreef op 14 October 2003 @ 14:22:
[...]
Sorry, maar ik begrijp je nog niet helemaal.

Sorry, Ik bedoelde een order by. Zodat dezelfde producten bij elkaar staan.

[..]
Kun je misschien een klein beetje meer uitleggen hoe jij de query dan ziet, en de verdere opbouw van de layout naar de gebruiker daarin oplost?

je selecteert al je velden, order by zodat dezelfde producten bij elkaar staan, eventueel gesorteert op grootte.

Zodra jij dan in je programmeertaal de resultaten ophaalt kan je ontdekken als het product veranderd, zodra dat dus is druk je dus het product naam e.d af. En anders is het dezelfde product als de laatste, dus geef je alleen de type en grootte weer.

[Poiter]

Je moet 2 zaken hier heel goed scheiden, welke data moet ik hebben, en hoe wil ik het laten zien.
Je hebt alle data nodig, dus je query kan heel simpel zijn :

SELECT produktmerk, produktnaam, produktformaat, produktprijs FROM producten;

Eventueel nog met een ORDER BY zoals al gezegt.

De opmaak zul je in je client moeten doen
Er zijn programmeer-talen die zijn gespecialiseerd in het maken van lijsten/rapporten, en waarmee het rapport wat jij wil een fluitje van een cent is (bv PowerBuilder). In andere talen kan dat een stuk moeilijker zijn...

[xshredx]

Tjah, bedankt voor het meedenken hoor, maar deze oplossing lijkt me nog niet ideaal.
Hoe kan ik bijvoorbeeld met jullie methode verscheidene pagina's inbouwen (bv. 1000 produkten laten weergeven in 10 pagina's van 100)?

Als ik gewoon een order by doe en dan met de programmeertaal langs alle resultaten fiets, en zo kijk of de produkten veranderen, dan kan ik toch geen verscheidene pagina's inbouwen?
Ik kan natuurlijk wel het aantal verschillende produkten opvragen (select distinct count...) aan de database, maar als ik een pagina opbouw door gewoon de produkten te overlopen en te kijken wanneer de naam verandert, kan ik toch niet weten met hoeveel unieke produkten een set records overeenkomt?

Als het met de huidige structuur niet mogelijk zou zijn om dit te doen, hoe zoe ik de databasestructuur dan best veranderen.
Ik dacht aan een structuur met twee tabellen waarbij de ene tabel er zo uitziet:

produktid - produktmerk - produktnaam

1 - merk1 - produkt1
2 - merk2 - produkt2

en een tweede tabel die de formaten en hun prijs opslaat:

produktid - formaat - prijs

1 - formaat1 - 10
2 - formaat1 - 20
2 - formaat2 - 25


... maar dan vrees ik dat ik nog altijd vastzit aan het feit dat bij het afdrukken van een lijst (of een gedeelte, bv. produkt500 t/m 600), voor elk produkt een query moet doen om de formaten op te halen.
Wat ik denk wat wel weer al beter zou zijn aan deze methode is dat informatie niet meer dubbel voorkomt (produktmerk en naam zijn toch hetzelfde, waarom dan als twee produkten beschouwen... als het eigenlijk 1 produkt is dat onder verscheidene formaten te krijgen is).

Ik heb dus eigenlijk de vraag hoe ik het beste een variabel aantal gelijksoortige eigenschappen (de formaten met bijhorende prijs) van 1 produkt het beste kan opslaan. Ik vrees dat ik een beetje de ervaring mis om deze gegevens op een goede manier te structureren.
Als de huidige structuur veranderd moet worden, fine... dan schrijf ik daar wel een convertertje voor, en da's maar eenmalige moeite dan. Maar dan moet ik wel een structuur vinden die makkelijker werkt, en die zie ik, waarschijnlijk door mijn beperkte database ervaring, niet.
(iets opzoeken is geen probleem (behalve dat ik de group by wel kende, maar totaal niet begreep wat die hier kwam doen), maar dit is een probleem waarbij ik gewoon de beste werkwijze niet zie, en graag wat input zou willen)

[Brothar]

Vertel nu eens precies wat je wilt:
Je kunt de gegevens uitdraaien met group by.
Maar wat wil je nu met je laatste post ? Het netjes kunnen printen ? En wat houdt dat dan voor jou in, en waarom kun je dat niet met een programma als Crystal Reports of iets dergelijks ?

Zoals Poiter al zegt: de opmaak doe je in je client.

[ Voor 10% gewijzigd door Brothar op 15-10-2003 00:22 ]