Rendezésről ismét

Ha már az előző bejegyzést a rendezésnek szenteltem, gondoltam írok még egy kicsit róla. Ez nem SQL Server 2012 újdonság, csak most találkoztam vele. Lehet olyan agymenésünk (vagy a megrendelőknek), hogy egy lekérdezés eredményét egy mező értékétől függően eltérően kell rendezni. Például a nőket ABC sorrendbe szeretnénk látni, a férfiakat is ABC sorrendben de csökkenő irányban, vagy esetleg a férfiakat meg beosztások szerinti sorrendbe szeretné látni. Ekkor jön jól, hogy lehet CASE kifejezést használni az order by listán. Nézzük azt ha különböző rendezés irányokat szeretnénk használni:

use AdventureWorks2012
go 

select p.LastName, p.FirstName, e.Gender,e.MaritalStatus,e.JobTitle,p.BusinessEntityID
from HumanResources.Employee e
inner join Person.Person p on e.BusinessEntityID=p.BusinessEntityID
order by 
    case  when e.Gender= 'M' then p.LastName end desc
    ,case when e.Gender= 'F' then p.LastName end       



A fentihez teljesen hasonlóan lehet megadni, ha különböző szempontok szerint szeretnénk rendezni őket:

use AdventureWorks2012
go 

select p.LastName, p.FirstName, e.Gender,e.MaritalStatus,e.JobTitle,p.BusinessEntityID
from HumanResources.Employee e
inner join Person.Person p on e.BusinessEntityID=p.BusinessEntityID
order by 
    case  when e.Gender= 'M' then e.JobTitle end 
    ,case when e.Gender= 'F' then p.LastName end 
De mi a helyzet, ha figyelembe vesszük, hogy a teljes név több oszlopból áll, ekkor miképp kell megadni a rendezést? Ekkor gyakorlatilag rendezési mezőnként meg kell írni a case kifejezést
use AdventureWorks2012
go 

select p.LastName, p.FirstName, e.Gender,e.MaritalStatus,e.JobTitle,p.BusinessEntityID
from HumanResources.Employee e
inner join Person.Person p on e.BusinessEntityID=p.BusinessEntityID
order by 
    case  when e.Gender= 'F' then p.LastName end 
    ,case when e.Gender= 'F' then p.Firstname end  
    ,case  when e.Gender= 'M' then p.LastName end desc
    ,case when e.Gender= 'M' then p.Firstname end desc 

Azt lehet megfigyelni, hogy egy olyan order by-t adtunk meg amely négy oszlopot tartalmaz, mely a nők esetén az utolsó két oszlop értéke null, a férfiak esetében meg az első két oszlopa null. Ezzel a technikával diszjunkt halmazokon egymástól független rendezéseket tudunk megadni.



Kovács Ferenc

Kovács Ferenc 1998-ban végeztem villamosmérnökként a Budapesti Műszaki Egyetemen, azóta főleg adatbázis technológiákkal és adatbányászati algoritmusok fejlesztésével foglalkozom. A BME Automatizálási és Alkalmazott Informatikai Tanszékén oktatok az egyetem elvégzése óta, 2000-től kezdődően folyamatosan vannak adatbázisokkal foglalkozó kurzusaim. Az egyetemi oktatás mellett szoftverfejlesztőként dolgoztam a Multisoft KFT-nél, valamint a Philips Speech Processing részlegénél.

2012.03.30. 19:19:36 | Permalink | Hozzászólások: 0 | Tárgyszavak: ,


  • Property BackupDirectory is not available - SQL Backup hiba

    Dávid Zoltán Szegény embert az ág is húzza: most éppen nem szeretnék backupolni, de nem is tudok, pedig kéne. Az ok, hogy SQL Server Management Studioban az alábbi hibaüzenet fogad, ha Jobbklikk –> Tasks –> Backupot nyomok: “Property BackupDirectory is not available for Settings 'Microsoft.SqlServer.Management.Smo.Settings'. This property may not exist for this object, or may not be retrievable due to insufficient access rights.  (Microsoft.SqlServer.Express.Smo)” Tovább »
  • Barátságos HTTPS átirányítás

    Balássy György (MS RD, ASP.NET MVP, MCTS) Gyakori üzemeltetői feladat, hogy egy oldalt csak biztonságos HTTPS csatornán keresztül szeretnénk elérhetővé tenni. Sajnos nem minden üzemeltetőnek tűnik fel, hogy az is a feladat része, hogy az apró “s” betűt be nem gépelő felhasználókat barátságosan átirányítsuk a biztonságos címre: tegye fel a kezét, aki még nem látott 403.4 Forbidden: SSL is required to view this resource hibaüzenetet. Na ugye. Mennyivel szebb lenne, ha az alapértelmezett hibaüzenet helyett eljuttatnánk a felhasználót oda, ahova indult, csak éppen nem HTTP-n, hanem HTTPS-en keresztül. Tovább »


Írja meg Ön is véleményét!


Hozzászólásokat csak regisztrált, bejelentkezett felhasználóktól tudunk elfogadni!

Hozzászólások