MYSQL SET REPLACE naam waar een ' in zit

[Alientrader]

Ik zit te hannesen,

Ik heb een database waarin ik alle verwijzingen van 's-Gravenhage moet vervangen naar Den Haag.


de SQL Query zou dit moeten zijn: Echter ik weet niet hoe ik de dubbele ' afvang in de query..


UPDATE tabelnaam SET Plaats = REPLACE(Plaats, 'Foute Stadnaam', 'Goede Stadnaam')


het is echt iets kleins en ik ben helaas geen mysql guru

[CyBeR]

een \ er voor zetten, of dubbele quotes (") gebruiken aangezien mysql dat gewoon snapt.

[ Voor 61% gewijzigd door CyBeR op 04-07-2018 16:14 ]

[CurlyMo]

Alientrader schreef op woensdag 4 juli 2018 @ 16:12:
UPDATE tabelnaam SET Plaats = REPLACE(Plaats, 'Foute Stadnaam', 'Goede Stadnaam')

Dan zou ik het alsnog niet zo doen, want je vangt mogelijke side-effects niet af.

SQL:

UPDATE tabelnaam SET plaats = 'Den Haag' WHERE plaats = '''s-Gravenhage';

Het zou nog mooier zijn om een stam tabel te maken met alle plaatsnamen en vanuit tabelnaam aan de stamtabel te relateren. Dan hoef je maar in één tabel op één rij de plaatsnaam te veranderen.

[Stoelpoot]

CurlyMo schreef op woensdag 4 juli 2018 @ 16:19:
[...]

Dan zou ik het alsnog niet zo doen, want je vangt mogelijke side-effects niet af.

SQL:

UPDATE tabelnaam SET plaats = 'Den Haag' WHERE plaats = '''s-Gravenhage';

Het zou nog mooier zijn om een stam tabel te maken met alle plaatsnamen en vanuit tabelnaam aan de stamtabel te relateren. Dan hoef je maar in één tabel op één rij de plaatsnaam te veranderen.

Mooier op normalisatieniveau misschien, maar de koppeling maakt queries ook trager. Als het gebruik van de database nooit de plaatsnaam als sortering of criteria gebruikt, maar wel vaak ophaalt als platte tekst, is dat onhandig.

[Alientrader]

CyBeR schreef op woensdag 4 juli 2018 @ 16:14:
een \ er voor zetten, of dubbele quotes (") gebruiken aangezien mysql dat gewoon snapt.

Bedankt de \ werkt idd.

[RobIII]

Stoelpoot schreef op woensdag 4 juli 2018 @ 16:23:
Mooier op normalisatieniveau misschien, maar de koppeling maakt queries ook trager.

Behalve in erg specifieke cases is die behoorlijk generieke uitspraak die je doet complete 🐂💩 In een doorsnee scenario is dat 'trager' volledig verwaarloosbaar en gaat het voordeel dat je hebt van een fatsoenlijk genormaliseerd model vele malen boven de zo-goed-als-verwaarloosbare effecten van een FK relatie.

[ Voor 21% gewijzigd door RobIII op 04-07-2018 16:38 ]

[Stoelpoot]

RobIII schreef op woensdag 4 juli 2018 @ 16:34:
[...]

[afbeelding]

Behalve in erg specifieke cases is die behoorlijk generieke uitspraak die je doet complete 🐂💩

Omdat de informatie die er is ook generiek is. Vandaar ook dat ik het verduidelijk met de casus waarin dit van toepassing is.

De database kan grote performance-eisen hebben, op tragere embedded hardware gebruikt worden, of kan wereldwijd gebruikt worden (flinke index). Bovendien is het niet nodig om een complexe referentie op te zetten als het enige wat nodig is een invulveldje op een profielensite is. Alleen in dit geval krijg je er echt last mee, en dan nog hoefde er maar een escape sequence voor.

Zoals ik zei is het qua normalisatie wel mooier. En een nanoseconde trager is ook trager, enkel verwaarloosbaar. Maar het is wel belangrijk om te weten dat het niet altijd zomaar "Ja maak er gewoon een stamtabel van" hoeft te zijn.

[Gomez12]

Stoelpoot schreef op woensdag 4 juli 2018 @ 16:23:
[...]
Mooier op normalisatieniveau misschien, maar de koppeling maakt queries ook trager. Als het gebruik van de database nooit de plaatsnaam als sortering of criteria gebruikt, maar wel vaak ophaalt als platte tekst, is dat onhandig.

Juist vanwege performance redenen wil je dit soort dingen gewoon wegnormaliseren. Dan praat je niet over nanosecondes, maar rustig over millisecondes tot secondes die je gaat opschieten met een behoorlijke normalisatie.

Je hebt extreem simplistisch gezegd 2 grote kampen in de dbms wereld, sql (/rdbms) en nosql.
En mysql is gewoon een rdbms, als je gaat opzoeken waar die r voor staat dan kan je ook begrijpen waar hun prioriteiten naar uitgaan. En dat is niet naar 10.000x hetzelfde varchar veldje maar van schijf halen.

En ook met embedded systems etc, daar is het efficiënter om 1x een varchar in het geheugen te hebben en daarnaast 2 integers dan 2x een varchar die gelijk is.

[CurlyMo]

Alientrader schreef op woensdag 4 juli 2018 @ 16:30:
[...]


Bedankt de \ werkt idd.

Houdt er rekening mee dat de backslash niet in alle databases werkt zoals postgresql. Een aanvullende enkele quote als escape wel.

[Dido]

Stoelpoot schreef op woensdag 4 juli 2018 @ 16:23:
Mooier op normalisatieniveau misschien, maar de koppeling maakt queries ook trager. Als het gebruik van de database nooit de plaatsnaam als sortering of criteria gebruikt, maar wel vaak ophaalt als platte tekst, is dat onhandig.

"Premature optimization", is een leuke term om eens te googlen.
Direct naar de 5e NV springen omdat er misschien wel performance edge-cases zouden kunnen zijn gaat erg ver.
In een rdbms normaliseer je gewoon alles uit, en je laat de database doen waar ie goed in is, namelijk het optimaliseren van queries op relationele databases.
Pas als je tegen een van die relatief zeldzame use-cases aanloopt waar je toch tegen performanceproblemen aan lijkt te lopen ga je misschien zelf eens aan performance-optimalisatie denken.

Reken voor de lol eens uit hoeveel milliseconden de TS nu extra kwijt is aan het maken can deze query, terwijl hij in een (beter) genormaliseerd datamodel 1 enkele update had kunnen doen, en dan nog gewoon op PK ook.

[Renzmeister]

Hoe ver je normaliseert is natuurlijk ook compleet afhankelijk van je use case. Bouw je een transactioneel systeem, dan normaliseer je je data inderdaad helemaal uit. Bouw je een datamart, wat in MySQL prima mogelijk is, dan ligt een dimensioneel sterschema meer voor de hand en kan het best zo zijn dat de plaatsnaam meerdere keren voorkomt in een dimensietabel. Moet je veel aggregeren op bijv. time series data, dan stop je het misschien in 1 platgeslagen tabel, maar dan is MySQL misschien wat minder geschikt.

[RobIII]

Renzmeister schreef op vrijdag 6 juli 2018 @ 09:33:
Hoe ver je normaliseert is natuurlijk ook compleet afhankelijk van je use case [...] blabla

We snappen dat je helemaal de bomshizzle bouwt in MySQL (of eender welk RDBMS) maar hoe is dat hier in vredesnaam relevant Laten we 't gewoon lekker ontopic houden. Het ging, for pete's sake, over 't escapen van een ' en dat een where clause wel handig zou zijn om niet de hele tabel te raken. Iemand laat zijdelings (terecht) vallen dat het hele probleem niet aan de orde zou zijn maar 1 record zou betreffen als het model goed genormaliseerd was. Als het hier om een 'datamart' ging hadden we dit topic nooit gezien, dus laten we 't nou niet in 't extreme doortrekken.

[ Voor 3% gewijzigd door RobIII op 06-07-2018 10:19 ]

[CurlyMo]

@Alientrader Misschien een goed idee om even het antwoord van @CyBeR als beste antwoord aan te merken.

[Renzmeister]

RobIII schreef op vrijdag 6 juli 2018 @ 10:18:
[...]

We snappen dat je helemaal de bomshizzle bouwt in MySQL (of eender welk RDBMS) maar hoe is dat hier in vredesnaam relevant Laten we 't gewoon lekker ontopic houden. Het ging, for pete's sake, over 't escapen van een ' en dat een where clause wel handig zou zijn om niet de hele tabel te raken. Iemand laat zijdelings (terecht) vallen dat het hele probleem niet aan de orde zou zijn maar 1 record zou betreffen als het model goed genormaliseerd was. Als het hier om een 'datamart' ging hadden we dit topic nooit gezien, dus laten we 't nou niet in 't extreme doortrekken.

Ik had het dan iets anders moeten formuleren: Ik ben het niet eens met de suggestie om verder te normaliseren, zonder dat je weet wat @Alientrader aan het bouwen is. Nou ook niet doen alsof ik de discussie tot in het extreme doortrek, zo exotisch waren mijn voorbeelden niet...Offtopic is het wel, maar dat was de discussie allang, dus ik laat het hier maar bij.