CDRN

Een SQL-query opmaken en inspringen

  • Dashboard
  • Documentatie
  • API
formatteert je SQL-queries om ze leesbaar en eenvoudig te onderhouden te maken

Waarom SQL opmaken?

SQL-opmaak maakt SQL-query's leesbaarder en begrijpelijker voor ontwikkelaars en databasebeheerders. Het vergemakkelijkt het debuggen, de codereview en de optimalisatie van query's. Goed opgemaakte SQL is essentieel om de codekwaliteit te behouden en efficiënt samen te werken binnen een ontwikkelteam.

Ondersteunde SQL-querytypen

Deze tool ondersteunt alle soorten SQL-query's, inclusief SELECT-, INSERT-, UPDATE-, DELETE-instructies, evenals instructies voor het maken en wijzigen van tabellen (CREATE, ALTER, DROP).

Hoe u SQL-query's opmaakt

Op de opmaakpagina kunt u uw SQL-query opmaken door deze in het daarvoor bestemde tekstgebied te plakken.

Zodra de SQL-query is ingediend, wordt deze opgemaakt en weergegeven in een resultaatgebied. Als de query ongeldig is, wordt een fout weergegeven met een indicatie van de aard van het probleem.

De opgemaakte SQL gebruiken

U kunt de opgemaakte SQL kopiëren met de daarvoor bestemde kopieerknop. Dit vergemakkelijkt de integratie van SQL-query's in uw projecten of rapporten.

Uw SQL-code zou er zo uit moeten zien: 


SELECT u.id, u.name, u.email,
       p.product_name, p.price,
       o.order_date, o.quantity,
       (SELECT SUM(p2.price * o2.quantity)
        FROM orders o2
        JOIN products p2 ON o2.product_id = p2.id
        WHERE o2.user_id = u.id) as total_spent
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE u.id IN (
    SELECT user_id
    FROM orders
    WHERE order_date >= '2023-01-01' AND order_date <= '2023-12-31'
    GROUP BY user_id
    HAVING COUNT(*) > 5
)
AND p.price > 50
ORDER BY u.name ASC, o.order_date DESC
LIMIT 10;

Veelgestelde vragen

Welke SQL-dialecten worden ondersteund: MySQL, PostgreSQL, SQL Server?

De opmaker herkent de standaard SQL-syntaxis (ANSI) evenals de belangrijkste uitbreidingen van MySQL, PostgreSQL, SQL Server (T-SQL), Oracle (PL/SQL) en SQLite. De sleutelwoorden die specifiek zijn voor elke engine (LIMIT van MySQL en PostgreSQL, TOP van SQL Server, RETURNING van PostgreSQL, MERGE) worden correct ingesprongen. Native functies die eigen zijn aan een engine worden zo bewaard zonder validatie.

Beheert de opmaker CTE's en recursieve query's?

Ja. CTE's (Common Table Expressions) gedeclareerd met WITH ... AS (...) worden ingesprongen op hun eigen blok, en recursieve CTE's (WITH RECURSIVE) worden herkend. Dit maakt complexe query's veel leesbaarder, met name hiërarchieën (bomen, grafieken) en schuifvensters. Gecorreleerde subquery's worden ook uitgelijnd met hun ouderbereik.

Wat is het verschil tussen een SQL-opmaker en een query-optimizer?

Een SQL-opmaker wijzigt de semantiek van de query niet: hij reorganiseert alleen visueel de code (regeleinden, inspringing, hoofdletters van sleutelwoorden). Een optimizer daarentegen herschrijft de query of stelt wijzigingen voor (ontbrekende indexen, joins die opnieuw moeten worden geordend, subquery's die moeten worden omgezet in joins) om de prestaties te verbeteren. Om het uitvoeringsplan te analyseren, gebruikt u EXPLAIN of EXPLAIN ANALYZE afhankelijk van de engine.

Worden SQL-commentaren bewaard?

Ja. Inline commentaren -- commentaar en meerregelige commentaren /* ... */ worden bewaard op hun oorspronkelijke plaats. Dat is essentieel om een complexe query te documenteren of secties te markeren (TODO, hint voor de optimizer, versie van een migratie). Als u de query doorgeeft aan een engine die commentaarhints (/*+ INDEX(...) */ op Oracle) interpreteert, worden deze ook bewaard.

Waarom worden SQL-sleutelwoorden in hoofdletters geplaatst?

Sleutelwoorden (SELECT, FROM, WHERE, JOIN) in hoofdletters plaatsen is een historische conventie die ze visueel onderscheidt van identifiers (tabelnamen, kolommen). Deze praktijk vergemakkelijkt het lezen, vooral in lange query's. Tabel- en kolomnamen worden daarentegen bewaard in hun oorspronkelijke hoofdlettergebruik om de schemaconventies te respecteren (in het bijzonder op PostgreSQL waar hoofdlettergebruik gevoelig is voor gequote identifiers).

Valideert de opmaker de SQL-syntaxis?

De opmaker voert een lichte syntactische analyse uit die grove fouten detecteert (niet-uitgebalanceerde haakjes, ontbrekende puntkomma aan het einde van een instructie, inconsistente sleutelwoorden). Het valideert niet het bestaan van tabellen en kolommen, noch de conformiteit met een specifiek schema. Daarvoor voert u de query uit in EXPLAIN-modus op uw database, of gebruikt u een speciale linter zoals sqlfluff.

Voorbeeldverzoek

curl -X POST https://cdrn.fr/api/v1/tools/sql-formatter/execute \
  -H "Content-Type: application/json" \
  -d '{"input":"..."}'

Invoerschema

Veld Type Vereist Standaard
input text ✓ –

Endpoints

  • GET https://cdrn.fr/api/v1/tools - toont alle beschikbare tools
  • GET https://cdrn.fr/api/v1/tools/sql-formatter - geeft het schema van deze tool terug
  • POST https://cdrn.fr/api/v1/tools/sql-formatter/execute - voert deze tool uit met een JSON-payload