[MySQL] rij uit db lezen als andere rij met zelfde id niet b

[zeekoe]

[MySQL] rij uit db lezen als andere rij met zelfde id niet bestaat (paste niet in topictitelvakje)
Dit heb ik:
[database]
id naam taal
1 sheep - en
1 schaap - nl
2 dog - en
2 hond - nl
3 pig - en
[/database]
Het is voor een website (php/mysql) in meerdere talen, die makkelijk vertaald moet kunnen worden. Vereiste is hier dat alle niet-vertaalde stukken tekst op een rijtje gezet kunnen worden.
Hiervoor is dus een mysql query nodig die de Engelse tekst bij een bepaald id laat zien, wanneer de Nederlandse tekst voor dat id niet bestaat. Nu ben ik nog niet zo gek lang met mysql aan het programmeren, maar het lijkt me dat zoiets wel mogelijk moet kunnen zijn. Ik heb alleen geen flauw idee hoe ik naar een goed antwoord zou kunnen googlen.
Andere opties
1. Alle talen in 1 database-rij. Nadeel: voeg een taal toe en je moet je hele tabel opnieuw maken
2. Alles uitlezen, en dan met php de array die mysql uitspuugt verder uitzoeken. Is onnodig veel werk, kost veel tijd, en de minst nette oplossing volgens mij.

[BM]

code:

Select *
From tabelnaam
Where Taal = 'en' and
ID not in (Select *
           From tabelnaam
           Where Taal='nl')

Volgens mij dit ongeveer zijn wat je zoekt, weet niet of de syntax helemaal correct is.

[ Voor 11% gewijzigd door BM op 18-12-2004 20:00 ]

[NMe]

MySQL kent pas vanaf versie 4.1 subqueries, dus dat werkt waarschijnlijk niet.

Is er een reden dat je de talen in een database zet? Ik vind aparte include files in PHP zelf een stuk makkelijker werken, en nog sneller ook. Gewoon een hele lijst met defines maken, of arrays, dat werkt een stuk makkelijker. Gewoon de taalfile includen die je nodig hebt, en je bent ready for business.

[jvdmeer]

SpeedAddict schreef op zaterdag 18 december 2004 @ 20:00:

code:

Select *
From tabelnaam
Where Taal = 'en' and
ID not in (Select *
           From tabelnaam
           Where Taal='nl')

Volgens mij dit ongeveer zijn wat je zoekt, weet niet of de syntax helemaal correct is.

Elke "not in" is ook als join te schrijven, dus:

code:

Select *
From tabelnaam t1
left join tabelnaam t2 on t1.id=t2.id
Where t1.Taal = 'en' and t2.Taal = 'nl' and t2.naam is null

[ Voor 22% gewijzigd door jvdmeer op 18-12-2004 22:30 . Reden: Suggestie gedaan zonder startpost te lezen, dus weggehaald ]

[NMe]

jvdmeer schreef op zaterdag 18 december 2004 @ 22:25:
of, als je maar twee talen gebruikt:

code:

Select ID From group by ID having count(*)<>2

Dan weet je niet of die ene taal dan wel de taal is die je zoekt.

[zeekoe]

-NMe- schreef op zaterdag 18 december 2004 @ 21:56:
MySQL kent pas vanaf versie 4.1 subqueries, dus dat werkt waarschijnlijk niet.

hmm jammer, zou wel makkelijk geweest zijn.

Is er een reden dat je de talen in een database zet? Ik vind aparte include files in PHP zelf een stuk makkelijker werken, en nog sneller ook. Gewoon een hele lijst met defines maken, of arrays, dat werkt een stuk makkelijker. Gewoon de taalfile includen die je nodig hebt, en je bent ready for business.

Inderdaad. Maar de tekst moet een beetje makkelijk te editen zijn enzo, ook door relatieve n00bs, soort van CMS. En dan zijn include files niet handig.

jvdmeer schreef op zaterdag 18 december 2004 @ 22:25:
Elke "not in" is ook als join te schrijven, dus:

code:

Select *
From tabelnaam t1
left join tabelnaam t2 on t1.id=t2.id
Where t1.Taal = 'en' and t2.Taal = 'nl' and t2.naam is null

Woei! Geniaal :-)
Ik had wel een beetje naar die join dingen gekeken, maar snapte het nog niet heel erg. Hier moet ik zeker wat mee kunnen (nog even kijken of ik bij het aanmaken van een taal gelijk al de andere moet doen, maar dan leeg, en dat soort kleine dingetjes). Allemaal bedankt voor de reacties!

[Verwijderd]

ook lijkt me db sneller dan een language file, filesystem is wat trager en ook laad je alles terwijl je de helft niet nodig hebt. + editen is beter in db

[Creepy]

Verwijderd schreef op zondag 19 december 2004 @ 22:33:
ook lijkt me db sneller dan een language file, filesystem is wat trager en ook laad je alles terwijl je de helft niet nodig hebt. + editen is beter in db

Je realiseert je dat in MySQL 1 database meerdere files is op je filesystem?

[NMe]

Verwijderd schreef op zondag 19 december 2004 @ 22:33:
ook lijkt me db sneller dan een language file, filesystem is wat trager en ook laad je alles terwijl je de helft niet nodig hebt. + editen is beter in db

Heb je daar bewijzen van? Een benchmark ofzo?

Editen gaat trouwens in een DB net zo makkelijk als in een tekstfile, dus dat is ook geen argument. Je zou zelfs kunnen zeggen dat een simpele tekstfile (PHP-file) beter werkt, omdat je die niet eerst hoeft te openen in een database management tool, maar gewoon in Kladblok of iets dergelijks.

[kvdveer]

Kom op mensen. Dat geneuzel over textfiles is onzin
Als databases niet nuttig zouden zijn geweest dan zouden er echt niet zoveel van hebben bestaan.

Voor het doel van de TS is een database de voordeligste keuze:
Vergelijking tussen textille en database:
[list]• Een database heeft indexes waardoor random access zoeken niet vereist dat je de hele textfile leest.
• Mysql heeft een server-daemon draaien, waardoor de filehandles open kunnen blijven.
• Mysql heeft ondersteuning voor locks, waardoor je niet je applicatie down hoeft te gooien als je teksten wijzigt. (anders zou je lockingproblemen krijgen)
• Als je in een database edit, dan heb je niet de kans je applicatie om zeep te helpen met een onbedoelde parse error.



Een database is gewoon sneller omdat het voor het ophalen van data onworpen is. Voor het opslaan van bestanden is een database niet zo snel - daar zijn bestandssystemen voor ontworpen. Voor het opslaan van lange lappen tekst zijn tekstfiles inderdaad sneller. Maar als je veel relatief korte tekstjes hebt dan is een database sneller.

[ Voor 7% gewijzigd door kvdveer op 19-12-2004 23:25 ]

[Noork]

Had je niet beter een andere relationeel db model kunnen gebruiken? Bijvoorbeeld de vertalingen in de kolommen en niet in een nieuwe regel.

ID | Taal_NL | Taal_EN

Of 2 tabellen. 1 voor taal, en 1 voor de items. Dit geeft je de mogelijkheid om talen toe te voegen of te verwijderen.

TAALID | Taal

ITEMID | TAALID | Tekst

Ik draag geen oplossing aan voor je probleem. Maar misschien kun je eerst eens kijken hoe je aan dit probleem komt.

[ Voor 9% gewijzigd door Noork op 19-12-2004 23:30 ]

[Verwijderd]

een database gaat even wat sneller om met je data. en hoeft niet alles te lezen (daar is dus een index voor) een text file moet je WEL helemaal inlezen voordat je zeker weet dat je hebt wat je zoekt. Ook moet je dan weer je rechten aanpassen op de verschillende bestanden e.d.

[Verwijderd]

Noork schreef op zondag 19 december 2004 @ 23:30:
Had je niet beter een andere relationeel db model kunnen gebruiken? Bijvoorbeeld de vertalingen in de kolommen en niet in een nieuwe regel.

ID | Taal_NL | Taal_EN

Dit is natuurlijk een ramp als je later duits, spaans enz wilt toevoegen. Ook is dit in strijd met de basis normalisatieregels. Trouwens, de vraag wordt hier enkel lastiger door. nu moet je ofwel meerdere velden opvragen ( = meer data, = trager) en in de code die de gegevens opvraagt de boel checken. ofwel een IF in je query gebruiken wat ook niet echt efficient is.

Of 2 tabellen. 1 voor taal, en 1 voor de items. Dit geeft je de mogelijkheid om talen toe te voegen of te verwijderen.

TAALID | Taal

ITEMID | TAALID | Tekst

Dit is geen oplossing. De vraag veranderd dan in Hoe krijg ik een item uit de ITEMS tabel als het ITEMID wel bestaat maar enkel met een andere TAALID als het TAALID wat ik opvraag. Komt dus op hetzelfde neer, enkel het taalveld is veranderd in een TAALID veld. Dat het handiger is om de omschrijving van de taal (en, de, es, nl enz) niet hardcoded in de tabel te zetten is natuurlijk waar maar in dit geval niet echt relevant voor de TS

[Noork]

Verwijderd schreef op dinsdag 21 december 2004 @ 00:07:
[...]

Dit is natuurlijk een ramp als je later duits, spaans enz wilt toevoegen. Ook is dit in strijd met de basis normalisatieregels. Trouwens, de vraag wordt hier enkel lastiger door. nu moet je ofwel meerdere velden opvragen ( = meer data, = trager) en in de code die de gegevens opvraagt de boel checken. ofwel een IF in je query gebruiken wat ook niet echt efficient is.

Inderdaad een ramp om een extra taal toe te voegen. Dat zal ik niet ontkennen. Maar in strijd met welke normalisatieregels is dit dan? Je hoeft ook niet elke keer alle data op te halen. Met sql kun je heel goed een "Select Taal_NL from tabel" uitvoeren.

[...]
Dit is geen oplossing. De vraag veranderd dan in Hoe krijg ik een item uit de ITEMS tabel als het ITEMID wel bestaat maar enkel met een andere TAALID als het TAALID wat ik opvraag. Komt dus op hetzelfde neer, enkel het taalveld is veranderd in een TAALID veld. Dat het handiger is om de omschrijving van de taal (en, de, es, nl enz) niet hardcoded in de tabel te zetten is natuurlijk waar maar in dit geval niet echt relevant voor de TS

Ik zei ook niet dat ik direct een oplossing voorschreef. Die is boven al gegeven in de vorm van een join sql statement. De boel wordt gewoon wat overzichtelijker en je zit niet meer met dubbele insert statements. Ook kun je in mijn 2e datamodel eenvoudig een taal toevoegen en je hoeft niet 1 op 1 de site te vertalen.

[zeekoe]

TAALID | Taal

ITEMID | TAALID | Tekst

Is dit niet gewoon een manier van ingewikkelder schrijven van
ITEMID | Taal | Tekst ? Of begrijp ik je niet? Ik zie het nut nl. niet echt.

Had je niet beter een andere relationeel db model kunnen gebruiken? Bijvoorbeeld de vertalingen in de kolommen en niet in een nieuwe regel.

ID | Taal_NL | Taal_EN

Dat is idd precies de oplossing die ik had gekozen als uit dit threadje niets was gekomen. Maar zoals Jan Klaassen al zegt wordt het idd wat ingewikkelder als je een taal erbij wilt hebben. Moet je code gaan maken die automatisch een hele tabel gaat copypasten. Maar als ik voor het probleem in de eerste post een oplossing zou krijgen (die ik nu dus heb), zou ik dat netter vinden.

[Verwijderd]

Noork schreef op dinsdag 21 december 2004 @ 00:31:
[...]

Inderdaad een ramp om een extra taal toe te voegen. Dat zal ik niet ontkennen. Maar in strijd met welke normalisatieregels is dit dan?

Ehm, misschien de éérste NF?
http://databases.about.com/od/specificproducts/l/aa1nf.htm

Je hoeft ook niet elke keer alle data op te halen. Met sql kun je heel goed een "Select Taal_NL from tabel" uitvoeren.

Om mezelf maar eens te quoten

nu moet je ofwel meerdere velden opvragen ( = meer data, = trager) en in de code die de gegevens opvraagt de boel checken. ofwel een IF in je query gebruiken wat ook niet echt efficient is.

Als je de Nederlandse omschrijving wilt hebben en als die niet bestaat de engelse heb je (min of meer) drie opties.

- Select TAAL_NL from table En daarna als die niet bestaat Select Taal_EN from table (twee queries, twee velden en dus meer data)
- Select TAAL_NL,TAAL_EN from table en in je code testen (if Taal_NL=null then ...) Weer twee velden maar nu zelfs altijd.
- Select (IF TAAL_NL!=null,TAAL_NL, TAAL_EN) from table. De "beste" methode bij deze tabel structuur, altijd slechts 1 veld maar niet echt standaard SQL.

Met een tabel structuur die wel aan de 1 NF voldoet kun je standaard SQL gebruiken en toch slechts 1 veld ophalen.. Dat heeft dus performance voordelen en is ook portable.

Ik zei ook niet dat ik direct een oplossing voorschreef. Die is boven al gegeven in de vorm van een join sql statement. De boel wordt gewoon wat overzichtelijker en je zit niet meer met dubbele insert statements. Ook kun je in mijn 2e datamodel eenvoudig een taal toevoegen en je hoeft niet 1 op 1 de site te vertalen.

Punt was simpel dat jou tweede oplossing niet afweek van wat de TS zelf als originele structuur had. Enige verschil, jij werkt met Integer TAALIDs. hij met Alfanumerieke IDs ('en', 'de',....) Trouwens er zit nog wel 1 klein nadeel aan deze structuur. Als ik de omschrijving van een taal in meerdere talen wil opslaan gaat dit niet werken. Dus Nederlands, Dutch, Niederlandisch, enz. past niet in de tabel TAALID| Talen. Als je dat wilt zou je eigenlijk een tabel TAALID|ITEMID (eventueel TAALID|ITEMID|TAAL_CODE) moeten maken en de omschrijving in de ITEM tabel moeten stoppen.

[Noork]

Verwijderd schreef op dinsdag 21 december 2004 @ 07:26:
[...]
Ehm, misschien de éérste NF?
http://databases.about.com/od/specificproducts/l/aa1nf.htm

1NF: Meerwaardige of samengestelde meerwaardige attributen zijn niet toegestaan.

Hier is geen sprake van aangezien Taal_NL Taal_EN andere attributen zijn.

[...]
Punt was simpel dat jou tweede oplossing niet afweek van wat de TS zelf als originele structuur had. Enige verschil, jij werkt met Integer TAALIDs. hij met Alfanumerieke IDs ('en', 'de',....)

De TS had maar 1 tabel. De zogenaamde "id's" en, de, nl enz, zijn dus geen echte foreign keys. Bovendien is er geen unieke primairy key in de constructie van de TS.

Trouwens er zit nog wel 1 klein nadeel aan deze structuur. Als ik de omschrijving van een taal in meerdere talen wil opslaan gaat dit niet werken. Dus Nederlands, Dutch, Niederlandisch, enz. past niet in de tabel TAALID| Talen. Als je dat wilt zou je eigenlijk een tabel TAALID|ITEMID (eventueel TAALID|ITEMID|TAAL_CODE) moeten maken en de omschrijving in de ITEM tabel moeten stoppen.

Jajaja, er zijn nog tig nadelen die je er kan bij betrekken en hier is helemaal niet over gesproken.

Dit topic gaat nu echt nergens meer over. De TS is geholpen. Ik wilde hem alleen even op z'n onlogische constructie wijzen. Ik wil het verder hier bij laten.