Ik heb een query waarmee ik alle producten binnen een prijsrange wil ophalen. Dat werkte prima voordat ik prijzen heb opgeslagen met commas erin.
Dit is mijn query:
SELECT *
FROM (
SELECT cnt.id AS content_id,
cnt.title AS content_title,
cnt.featured,
cnt.ordering,
cnt.alias AS content_alias,
cnt.catid,
cnt.images,
cnt.state,
cnt.introtext,
cat.parent_id,
cat.id AS cat_id,
cat.title AS cat_title,
cat.alias AS cat_alias,
Max(
CASE
WHEN f.field_id = 6 THEN f.value
END) AS prijs,
Max(
CASE
WHEN f.field_id = 7 THEN f.value
END) AS prijsoud,
Max(
CASE
WHEN f.field_id = 8 THEN f.value
END) AS afbeelding
FROM snm_categories cat
LEFT JOIN snm_content cnt
ON cnt.catid = cat.id
AND cnt.state = 1
LEFT JOIN snm_fields_values f
ON cnt.id = f.item_id
WHERE cat.parent_id = 8
GROUP BY cnt.id,
cnt.title,
cnt.featured,
cnt.alias,
cnt.catid,
cnt.images,
cnt.state,
cnt.introtext,
cat.id,
cat.title,
cat.alias )t
WHERE prijs BETWEEN 154.95 AND 314.95
AND t.content_id IS NOT NULL
ORDER BY ordering
De waardes in de database zijn (laagste en hoogste) 154,95 en 314,95, het aanpassen van de query naar commas werkt niet, dan stopt hij helemaal met werken. Zoals hij nu is zie ik via mijn prijsfilter alleen het product met de hoogste prijs, het product van 154,94 wordt niet getoond.
Of gewoon even een conversieslag en de varchars-met-prijs (ik neem aan dat het dat zijn) als een echte decimal of float opslaan. Prijzen in centen opslaan is ook altijd weer zo'n gedoe met rekenen en presenteren (x100, /100, op een gegeven moment vergeet je het een keer en staat alles te duur/goedkoop op de site).
[size=xsmall]Toevoeging op 14/02/2019 20:11:29:[/size]
Maar dit werkt blijkbaar ook al (geen expliciete cast nodig):
WHERE replace(prijs,',','.') BETWEEN 154.95 AND 314.95
Hoef je dan geen CAST te doen? Anders is het toch een alfabetische vergelijking in plaats van een numerieke vergelijking? Kom je dan niet in de problemen? Wellicht lost die BETWEEN het op? REPLACE lijkt mij nog steeds niet erg efficiënt. En los daarvan lijkt het mij beter om getallen (al dan niet met decimalen) ook echt in een soort van numerieke kolom op te slaan.
Er is iets mis met je database-ontwerp op het moment dat je je data eerst nog moet gaan vertalen voordat je deze kunt gebruiken.
Hoef je dan geen CAST te doen? Anders is het toch een alfabetische vergelijking in plaats van een numerieke vergelijking? Kom je dan niet in de problemen? Wellicht lost die BETWEEN het op? REPLACE lijkt mij nog steeds niet erg efficiënt. En los daarvan lijkt het mij beter om getallen (al dan niet met decimalen) ook echt in een soort van numerieke kolom op te slaan.
Er is iets mis met je database-ontwerp op het moment dat je je data eerst nog moet gaan vertalen voordat je deze kunt gebruiken.
Ik gebruik joomla als basis en de velden waar deze waardes vandaan komen zijn prijsvelden dus de gebruiker (een nederlander) gaat commas gebruiken in plaats van punten. En om nou aan de joomla structuur te gaan rommelen.. dan los ik het liever anders op. Ik ga het is met bovenstaande proberen te fixen.
Opslag in de database staat in feite (redelijk) los van presentatie in de browser. Kortom, in de webapp kun je best getallen met comma's presenteren, terwijl je in de database deze bedragen opslaat als "decimal". Persoonlijk zou ik geen "float" gebruiken overigens.
Opslag in de database staat in feite (redelijk) los van presentatie in de browser. Kortom, in de webapp kun je best getallen met comma's presenteren, terwijl je in de database deze bedragen opslaat als "decimal". Persoonlijk zou ik geen "float" gebruiken overigens.
Ja snap ik maar dat opslaan gebeurd dus door Joomla en ik ga liever niet in de code van Joomla zitten veranderen. Een andere optie is aan de gebruiker uitleggen dat hij punten gebruikt in plaats van commas, maarja met bovenstaande code is het al opgelost.
En om nou aan de joomla structuur te gaan rommelen..
Hoe slaat Joomla dit dan op?
En wat @Nick zegt: je kunt dit prima opslaan als een decimaal getal met een punt zodat je er makkelijk mee kunt rekenen. Hoe je dit verder weergeeft is vers twee.
[quote="Snelle Jaap op 15/02/2019 10:30:28"]En om nou aan de joomla structuur te gaan rommelen..
Hoe slaat Joomla dit dan op?
En wat @Nick zegt: je kunt dit prima opslaan als een decimaal getal met een punt zodat je er makkelijk mee kunt rekenen. Hoe je dit verder weergeeft is vers twee.
[/quote]
Het is een textveld, dus gewoon als string. Wanneer je 149,99 invoert dan slaat hij ook 149,99 op in de database.
Mja maar dingen textueel vergelijken is iets anders dan dingen numeriek vergelijken. Dus tenzij er op een of andere manier een typecast plaatsvindt zou dit soms onvoorspelbare resultaten kunnen geven (zelfs als je het in het goede formaat maar in een tekstuele kolom opslaat):
Ik kan me niet voorstellen dat daarin de prijzen opgeslagen worden als tekst. Dat zou namelijk betekenen dat bij het optellen van de bedragen in je winkelmandje al rekening gehouden moet worden met alle opties die een beheerder kan hebben verzonnen om bedragen op te slaan:
- 4.95
- 4,95
- € 4.95
- € 4,95
- 495
- 4,95 EUR
Daar kun je nooit mee rekenen.
Weet je zeker dat het hier om het prijs-veld gaat en dat er niet een of ander veld van de product-beschrijving wordt misbruikt voor de prijs?
Het feit dat je werkt met field_id;-value paren, lijkt daar al op te wijzen.
