Er is altijd een manier. De vraag is "Moeten we dit doen". Merk op dat je hiermee de merkgegevens verbergt. Als de gegevens opnieuw worden geordend, gesorteerd, verliest de sorteerder de mogelijkheid om te weten welk merk voor welke rij is. Als dit slechts een afgedrukt rapport is dat niet moet worden gebruikt of verwacht wordt naar een PDF waar een gebruiker de gegevens niet kan manipuleren, ok.. Maar als dit zo is, kan een gebruiker dumpen om uit te blinken en later te manipuleren... beter om te hebben alle gegevens.
Persoonlijk vind ik deze weergave van informatie onsmakelijk op elektronische gegevens, maar oké op gedrukte formulieren of statische rapporten. De reden:op elektronisch kan ik in Excel sorteren en met de gegevens spelen; maar als kolommen overbodige gegevens "ontbreken", wordt elektronische manipulatie problematisch.
CREATE Table foo (
brand varchar(20),
description varchar(20),
prodcode varchar(20));
Insert into foo values ('Brand1', 'Description1', 'Product1'),
('Brand1', 'Description2', 'Product2'),
('Brand1', 'Description3', 'Product4'),
('Brand2', 'Description3', 'Product4'),
('Brand2', 'Description3', 'Product4'),
('Brand1', 'Description3', 'Product3');
VRAAG:
SELECT case [email protected] <> f.brand then @Var :=brand end as Brand
, f.description
, f.prodcode
FROM (SELECT * FROM foo ORDER BY brand, description, prodcode) f
CROSS JOIN (SELECT @var := '') b
RESULTATEN:
Brand description prodcode
Brand1 Description1 Product1
(null) Description2 Product2
(null) Description3 Product3
(null) Description3 Product4
Brand2 Description3 Product4
(null) Description3 Product4
Waarom dit werkt:
De magie gebeurt in de cross join en bij de case-evaluatie.
Er is 1 tafel. We sorteren de records voordat we lid worden. We maken een gebruikersvariabele met de naam @var en stellen deze in op '' op het eerste record in tabel foo. Dan wijzen we @var toe aan het merk van de eerste plaat. Wanneer het SQL-kruis samenkomt met de 2e gearchiveerde @var is nu het merk van het eerste record. Als de merken overeenkomen, wordt er geen record weergegeven, als de merken niet overeenkomen, wijzigen we de waarde van @var en geven we de nieuwe waarde weer.
Risico's:
- Als er andere tafel-joins optreden, of als de volgorde niet is zoals gewenst in de tabel, moeten we eerst een subquery doen op "foo" om op merk te bestellen
- het toepassen van een bestelling door hierop waarbij brand1 betrokken is, is nu waardeloos
- Het is niet zo herbruikbaar. Een andere module die mogelijk gebruik wil maken van de gegevens (weergave) kan dit niet langer doen omdat het merk op sommige records is verborgen.