PostgresQL: utesluta från DISTINCT

2004-08-25 14:45

#1

scooterbabe
Medlem ●
International user
2004-08-25 14:45

Är det möjligt?

Vad jag vill göra är att om språksträng till det referenade id:et i huvudtabellen inte existerar, ska bara nästa språk väljas...

SQL:

SELECT
opskrifter_content.id,
CASE 
WHEN maengde IS NULL THEN languagesb.text
ELSE translate(round(maengde,3) || ' ' || languagesb.text, '.', ',')
END  AS maengde,
maengde as maengde_maengde,
languagesb.text AS enhed,
opskrifter_enhed.id as enhedsid,
betegnelse as ingrediens,
opskrifter_content.ingrediens as ingrediensid,
meat 
FROM (((
opskrifter_content 
JOIN 
view_opskrifter_unioningredienser 
ON 
opskrifter_content.ingrediens = view_opskrifter_unioningredienser.id) 
LEFT JOIN 
opskrifter_enhed 
ON 
opskrifter_content.enhed = opskrifter_enhed.id) 
LEFT JOIN 
(select * from languages order by lang = 'DK' desc) AS languagesb 
ON 
opskrifter_enhed.enhed = languagesb.relid)

Ger resultatet:

Vad jag vill göra är att DISTINCT:a resultatet efter id, och om det finns fler än en rad med samma id ska den översta väljas...

Kom igen nu, SQL-gurus; vässa geniknölarna!

/.scooter

Senast redigerat 2004-08-25 14:59

Anmäl Ändra Gilla Svara

2004-08-25 15:08

#2

scooterbabe
Medlem ●
International user
2004-08-25 15:08

Fann det själv i manualen:

Citat:

DISTINCT ON ( expression [, ...] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. The DISTINCT ON expressions are interpreted using the same rules as for ORDER BY (see above). Note that the "first row" of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. For example,
SELECT DISTINCT ON (location) location, time, report
FROM weather_reports
ORDER BY location, time DESC;

retrieves the most recent weather report for each location. But if we had not used ORDER BY to force descending order of time values for each location, we'd have gotten a report from an unpredictable time for each location.

The DISTINCT ON expression(s) must match the leftmost ORDER BY expression(s). The ORDER BY clause will normally contain additional expression(s) that determine the desired precedence of rows within each DISTINCT ON group.

Är nog inte SQL92-standard, men vaffan; bara det funkar så

Anmäl Ändra Gilla Svara

2004-08-25 20:53

#3

Samuel K
Medlem ●
Umeå
2004-08-25 20:53

Ska man vara lite pragmatisk kan det annars vara nog så bra att undvika särskilda söktabeller för varje flerspråkigt attribut (t.ex. produktnamn) och i stället bara skapa en textkolumn som man fyller med YAML-data. Syck (den vanligaste yaml-parsern) är så snabb att prestandaförlusten blir löjligt låg, och hela lösningen blir väldigt elegant.

Och tro mig - jag gjorde exakt samma sak som du gör nu (d.v.s. en särskild flerspråkstabell) i ett nyss färdigställt flerspråkigt jätteprojekt (~10k rader kod), och såhär i efterhand törs jag säga att det faktiskt var ett mycket stort misstag från min sida. SQL-satserna blir monstruösa och hopplösa att debugga och man måste köra med tabellalias ifall man behöver få ut mer än en flerspråkskolumn ur en SELECT-sats. Totalt sett blev hela databasbiten groteskt komplex jämfört med vad den kunde ha varit med en yaml-lösning, så just nu överväger jag faktiskt att skriva om precis hela den biten helt och hållet bara för att slippa det eländet. Så kom inte sedan och säg att jag inte varnade dig

Anmäl Ändra Gilla Svara

2004-08-26 10:38

#4

scooterbabe
Medlem ●
International user
2004-08-26 10:38

Men vilken skulle skillnaden vara mot att använda sig av xml i textkolumnen? XML-parsning är också snabbt, men det känns fortfarande som om man går över ån efter vatten, bortsett från att man får mindre SQL-satser...

Anmäl Ändra Gilla Svara

2004-08-26 21:25

#5

Samuel K
Medlem ●
Umeå
2004-08-26 21:25

Ursprungligen av scooterbabe:

Men vilken skulle skillnaden vara mot att använda sig av xml i textkolumnen? XML-parsning är också snabbt, men det känns fortfarande som om man går över ån efter vatten, bortsett från att man får mindre SQL-satser...

Går egentligen att använda vilken lagringsmetod som helst, men "the overhead of plain text files and the readability of binary files" sammanfattar min åsikt om xml ganska bra. XML är ett markupspråk, och som sådant fungerar det väldigt bra. Problemet är bara att de fall när man behöver just ett markupspråk är väldigt få, och xml är IMHO extremt missbrukat.

Normalt sett är jag inte alls någon förespråkare för att lagra vare sig yaml, xml eller liknande i textkolumner, men just i flerspråksfallet gör jag numera undantag. Ett SQL-baserat flerspråkssystem är extremt rörigt, buggar är hopplösa att hitta, och SQL-satser som annars hade blivit hur eleganta som helst förvandlas till 60-raders monster. Därför tycker jag att det är ett väldigt bra exempel på när man faktiskt gör bäst i att vara pragmatisk, men det är ju bara min högst personliga åsikt.

Anmäl Ändra Gilla Svara

2004-08-26 22:20

#6

HL
Medlem ●
Stockholm
2004-08-26 22:20

Jag är inte säker på att jag förstår problemet, men varför inte bara skapa en kolumn för varje språk istället för en kolumn för alla språk? Därmed inte sagt att man måste köra särskilda språktabeller som man måste JOINa ihop...

Anmäl Ändra Gilla Svara

2004-08-29 21:02

#7

Samuel K
Medlem ●
Umeå
2004-08-29 21:02

Ursprungligen av HL:

Jag är inte säker på att jag förstår problemet, men varför inte bara skapa en kolumn för varje språk istället för en kolumn för alla språk? Därmed inte sagt att man måste köra särskilda språktabeller som man måste JOINa ihop...

Det är inte alltid det låter sig göras. Vet man att man bara behöver bygga in stöd för, säg, två eller tre språk kan man ha en så pass statisk lösning, men i mitt fall hade det inte blivit särskilt bra (var inte alltför pigg på att behöva ha separata kolumner för spanska, samiska, kinesiska, etc.). Men visst, i enkla fall är det en snabb lösning som fungerar helt ok.

Anmäl Ändra Gilla Svara

PostgresQL: utesluta från DISTINCT

Senaste nytt