Direkta databasfrågor i WordPress

Om du gick igenom något av inläggen jag har skrivit under de senaste, låt oss säga, två åren, kommer du sannolikt att hitta mig som förespråkar att använda tillgängliga API:er över katalogdatabasfrågor nästan varje gång.

Och sanningen är att jag fortfarande lutar åt det hållet. Det vill säga, om det finns en abstraktion eller ett API som är tillgängligt för att göra något specifikt, då försöker jag använda det.

Men i ett par nya projekt har jag arbetat med några relativt stora datamängder (stora i jämförelse med datauppsättningar på icke-företagsnivå). Och genom att göra det har jag försökt se till att uppdateringarna av data sker så snabbt som möjligt.

I situationer som denna, även om WordPress-kodningsstandarderna inte gillar det, tycker jag att direkta databasfrågor ibland är det bästa alternativet för att göra det under vissa förhållanden.

Använda direkta databasfrågor

Direkta databasfrågor är en av de saker som har ett lite blandat rykte bland WordPress-utvecklare:

• de är avskräckta i kodningsstandarderna,
• WordPress erbjuder tillgång direkt till databasen via $wpdb,
• det finns nyanser i databasfrågor som bör förstås.

Så när du ser något sånt här :

<?php

private function set_all_scheduled_events_as_public() {

    global $wpdb;

    // @codingStandardsIgnoreStart
    $wpdb->query(
        $wpdb->prepare(
            "
            UPDATE $wpdb->posts
            SET post_status = '%s'
            WHERE post_type = '%s'
            AND post_status = '%s'
            ",
            'publish',
            'tribe_events',
            'future') );
    // @codingStandardsIgnoreEnd
}

Hur vet du om det är ett bra drag eller inte? Och ännu bättre, hur vet du om du ska använda katalogdatabasfrågor i din egen kod?

Det finns några frågor jag normalt ställer mig själv när jag hanterar dem alla som delas nedan.

1 Finns det index på kolumnerna?

Innan du använder direkta databasfrågor i WordPress är att kontrollera om kolumnerna jag frågar har index på nämnda kolumner.

Och anledningen är denna :

Index används för att snabbt hitta data utan att behöva söka på varje rad i en databastabell varje gång en databastabell används.

Summan av kardemumman är att hastigheten med vilken du kan fråga och uppdatera kolumner är snabbare om det finns index på kolumnerna.

Direkta databasfrågor beror på databasens struktur.

För det ändamålet är detta inte något som vi borde göra hela tiden. Men det finns tillfällen då det är lämpligt (som när du uppdaterar en uppsättning metavärden) och när det inte är det.

2 Parametrisera dina frågor

När du använder direkta databasfrågor är det extremt viktigt att parametrisera dina frågor för säkerhets skull. Du kan läsa allt om detta i Codex, och det här är inget att hoppa över.

Direkt från dokumentationen :

För en mer komplett översikt av SQL-escape i WordPress, se databasdatavalidering. Det är ett måste att läsa för alla WordPress-kodbidragsgivare och pluginförfattare.

Det vill säga, om du tar användarinput måste du se till att den är sanerad, ren och redo att infogas i databasen. Men för vad det är värt tillåter jag nästan aldrig användarinmatning att påverka direkta databasfrågor.

Istället är de normalt baserade på data som jag har i koden och vill uppdatera eller modifiera när de är säkert inom kontrollområdet för kodbasen.

3 Testa dem och testa dem igen

Och slutligen, innan jag implementerar några direkta frågor rekommenderar jag:

1. Starta ditt SQL-gränssnitt och kör frågorna,
2. Notera eventuella fel som de kan skapa,
3. Fixa dem och försök igen.

Sedan, när du har ett fungerande frågetest för kantfall för att se till att något inte kommer att försämras. Detta gäller särskilt om du ska använda LIKE-satser i dina frågor (vilket förmodligen är en artikel för sig själv).

Saknar jag ett API?

Med storleken på WordPress API finns det alltid en chans att jag missar något, försummar något eller helt enkelt inte är smart med de befintliga API:erna.

Och om så är fallet, så korrigerar jag gärna informationen som står ovan (så tveka inte att lämna en kommentar).

Men under tiden, om du arbetar med en relativt bestämd bit data, är du säker på att det finns index på kolumnerna, du vet hur du parametriserar frågorna, och du har testat data, och kanske gör med direkt databasfrågor är vägen att gå.

Och om så är fallet finns det några sätt att ignorera kodningsstandarderna utan att PHP CodeSniffer skriker åt dig. 🙂