Een *.sql file op syntax checken

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Front-End Developer – Junior/Medior/Senior

Onze opdrachtgever Onze opdrachtgever maakt kassa’s, personeelsplanning bar-/keukenmanagement, tafelreserveringssoftware, websites en webshops. Van horeca tot retail, van leisure tot zorg: elke ondernemer mag bij hun aankloppen. 24/7 spelen ze proactief in op de markt. Met softwareontwikkeling, projectmanagement, systeemimplementatie, helpdesk en technische dienst in eigen beheer bieden ze zo zekerheid voor haar klanten. Standplaats Hengelo Waar we jou voor nodig hebben? Van sterrenrestaurant tot vakantiepark: de klanten van onze opdrachtgever zijn heel divers. Een intuïtieve orderwebsite voor een grote cateraar of een sieradenplatform voor een juwelier, je draait er je hand niet voor om. Je communiceert helder en staat klanten graag

Bekijk vacature »

- Ariën -
Beheerder

- Ariën -

21/04/2019 22:57:50
Quote Anchor link
Een simpele vraag: Kent iemand een manier om een SQL-file op de syntax te controleren?
Voor mijn projecten maak ik geregeld een SQL-file voor de aanpassingen aan de database, maar het zou tof zijn dat ik tijdens het deployment of via een test-script direct kan zien of alles goed is, qua syntax.

Iemand een idee?
 
PHP hulp

PHP hulp

25/05/2019 12:21:00
 
Thomas van den Heuvel

Thomas van den Heuvel

22/04/2019 14:49:23
Quote Anchor link
Structurele wijzigingen worden altijd direct gecommit, dus als het hier om structurele wijzigingen gaat wordt dit lastig.

Wat eigenlijk nog veel belangrijker is is dat je altijd een soort van exit strategie hebt. Immers, wanneer een update om wat voor reden dan ook niet slaagt zou het kunnen zijn dat je ineens in de blubber vaststaat, met geen weg terug.

Dan is de vraag, hoe komt deze SQL-file tot stand, en waarom is er reden om aan te nemen dat dit niet altijd goed gaat?

Als je dit achterliggende probleem wegneemt, door bijvoorbeeld dit soort wijzigingen te testen op een (qua content en structuur) up-to-date ontwikkeldatabase -wat mij sowieso verstandig lijkt- dan kom je zelden tot nooit in de problemen lijkt mij?

Daarnaast is ook de vraag, hoe vaak verandert de structuur (aangenomen dat het om structuur gaat), kan dit tijdens een onderhoudscycle, is het mogelijk om backups te maken et cetera?

En als je heel vaak structurele wijzigingen hebt, dan klinkt het gewoon alsof er iets moet veranderen aan het ontwerp zelf.

Overigens, de makkelijkste manier om na te gaan of de syntax klopt lijkt mij nog steeds het simpelweg uitvoeren van de SQL.
 
- Ariën -
Beheerder

- Ariën -

23/04/2019 01:19:23
Quote Anchor link
Uiteraard test ik het op een test-locatie. Maar een controle vooraf of de syntax goed is, lijkt me geen overbodige luxe tijdens een deployment met de upgrade-scripts.

Het kán fout gaan als er een foutje in de migratie-SQLfile staat (elke versie verandert er wel iets aan de database, dat zit verder wel goed), maar het is zonde als ik weer de database moet leeggooien en opnieuw moet inladen etc. Dus daarom was ik benieuwd of er iets bestaat wat een reeks queries (in bijv. een sql-file) controleert. Desnoods een functie in MySQL / MariaDB ofzo.
Gewijzigd op 23/04/2019 01:21:00 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

23/04/2019 09:46:36
Quote Anchor link
Quote:
Uiteraard test ik het op een test-locatie. Maar een controle vooraf of de syntax goed is, lijkt me geen overbodige luxe tijdens een deployment met de upgrade-scripts.

Maar dat doe je toch op de testomgeving? Deze moet representatief zijn voor wat op productie actief is. Wat ben je anders aan het testen? Dus als je voor zo'n upgrade dan je database/content/whatever van productie terughaalt en de upgrade uitvoert en dat werkt, dan zou het op productie ook moeten werken. Tenzij jouw testomgeving niet representatief is voor je productieomgeving, en dan heb je een heel ander probleem.
Quote:
Het kán fout gaan als er een foutje in de migratie-SQLfile staat (elke versie verandert er wel iets aan de database, dat zit verder wel goed), maar het is zonde als ik weer de database moet leeggooien en opnieuw moet inladen etc.

Is wat je zegt niet tegenstrijdig? Volgens mij sluit je dit op de bovenstaande wijze uit, of je voorkomt in ieder geval op die manier dat je stront hebt op productie.

Neemt niet weg dat je dus meer maatregelen zou moeten treffen, zoals (in die volgorde):
- het sluiten van de site voor publiek tijdens onderhoud zodat er geen data meer kan worden gewijzigd
- het maken van een backup
- het doorvoeren van de wijziging(en)
- en natuurlijk ff testen of alles na afloop nog naar behoren werkt

Dit lijkt mij de enige manier om te waarborgen dat er niets mis kan gaan en als dat onverhoopt toch gebeurt dat je:
- terug kunt naar de werkende situatie door het terugzetten van de backup
- onderwijl kunt uitzoeken waarop de upgrade niet lukte en dan te besluiten om dat dan te repareren of de upgrade voorlopig maar uit te stellen

Daarbij is het ook verstandig om eens te testen of het terugzetten van de backup wel werkt anders is dat ook een wassen neus.

Je moet het zo zien: mits de omstandigheden/randvariabelen/toestand van de data op twee omgevingen hetzelfde zijn, dan zou het effect van eenzelfde wijziging in beide omgevingen hetzelfde resultaat moeten hebben. Dat is het fijne van (programma)code, die besluit niet zelf om ineens verschillende dingen te doen in een "identieke" setting.

Het kan ook enorm helpen om lijn aan te brengen in zo'n upgrade in de vorm van een procedure. Zorg dat de handelingen die je uitvoert altijd hetzelfde zijn en een voorschrift volgen. Dit helpt verder bij het verkleinen van de kans dat een upgrade mislukt. En als het dat toch misgaat, is dat waarschijnlijk 9 van de 10 keer te herleiden tot het niet volgen van de procedure en ligt dat niet aan de upgrade zelf.
Gewijzigd op 23/04/2019 09:53:58 door Thomas van den Heuvel
 
- Ariën -
Beheerder

- Ariën -

23/04/2019 09:59:10
Quote Anchor link
True, maar dat geeft nog geen antwoord op mijn vraag, of er een query-syntax- controleer-script bestaat. ;-)
Gewijzigd op 23/04/2019 10:02:38 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

23/04/2019 10:51:41
Quote Anchor link
Ik denk dat je je oplossing op de verkeerde plaats zoekt, maar wellicht biedt dit soelaas: https://www.eversql.com/sql-syntax-check-validator/
(5 minuten googlen overigens)
Gewijzigd op 23/04/2019 10:51:58 door Thomas van den Heuvel
 
- Ariën -
Beheerder

- Ariën -

23/04/2019 10:58:37
Quote Anchor link
Nee, ben er zeker van dat dit goed is. :-)
Ik zal eens kijken, maar ik zoek toch liever wel iets wat ik geautomatiseerd kan uitvoeren.

Edit: Ik heb gekeken naar die site, die je noemde, en die heeft moeite met meerdere queries onder elkaar, terwijl ze gewoon gescheiden zijn met een punt-komma.
Gewijzigd op 23/04/2019 11:56:55 door - Ariën -
 
Jelle Dnw

Jelle Dnw

23/04/2019 16:14:01
Quote Anchor link
Eigenlijk de beste manier is werken met database migraties ipv een hele file te committen (wie doet dat zelfs?).
Want je wil je productiedatabase toch niet gaan breken na een deploy?
 
- Ariën -
Beheerder

- Ariën -

23/04/2019 16:16:30
Quote Anchor link
Ik weet dat de meeste bekende frameworks gebruik maken van een migration-plan.
Maar goed, voor wat ik nu heb zoek ik toch echt graag een oplossing om een bestand met SQL-queries te controleren qua syntax.
Ook tijdens de ontwikkelingen wil je toch test-methodes ontwikkelen? Nietwaar?

Een framework met die mogelijkheid komt ooit eens, als ik er meer tijd voor heb.
Gewijzigd op 23/04/2019 16:18:05 door - Ariën -
 
Jelle Dnw

Jelle Dnw

23/04/2019 16:18:53
Quote Anchor link
Probeer eens wat rond te kijken op Github of op Packagist naar een SQLLinter die de SQL voor je valideert.

https://packagist.org/?query=sql%20validate
 
- Ariën -
Beheerder

- Ariën -

23/04/2019 16:19:52
Quote Anchor link
Hm, een goed idee! Ik ga eens rondneuzen.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.