Share
Als het gaat om het werken met op WordPress gebaseerde projecten, is het aantoonbaar een van de meest frustrerende of vervelendste aspecten van de implementatie om de databases in uw omgevingen synchroon met elkaar te krijgen.
Natuurlijk, er is iets te zeggen voor het gebruik van testgegevens in ontwikkeling, gebruikersgegevens in enscenering en werkelijke gegevens in de productie, maar er is niet zoiets als een zilveren kogel, toch? Dat betekent dat soms testgegevens gaan werken; andere keren zal het niet.
Laten we bijvoorbeeld zeggen dat u een project erven waarvan u een database moet verwijderen en vervolgens met bestaande gegevens kunt gaan werken. Of laten we zeggen dat u een hele site of applicatie van de ene naar de andere server moet migreren.
In dergelijke gevallen helpen testgegevens niet heel veel. In plaats daarvan heb je een tool daarvoor nodig. En ja, de WordPress Importer is een goede tool voor standaard migraties en het uitvoeren van SQL-exports en -importen is goed als je vertrouwd bent met frontends van databases en met SQL zelf werkt.
Maar hoe zit het met degenen die ergens tussenin staan?
De waarheid is dat het, als het gaat om het werken met WordPress-databasemigraties, een gemengde tas is omdat velen van ons niveaus hebben die variëren afhankelijk van welk deel van de stapel we met de meeste werken.
Daarmee bedoel ik:
Dit wil niet zeggen dat er geen full-stack-ontwikkelaars zijn. Uiteraard zijn er; echter, niet iedereen bevindt zich in die positie.
Dus als het gaat om het werken aan migrerende WordPress-databases, hebben sommige een veel moeilijkere tijd dan andere. Als alternatief, ondanks iemands comfortniveau met SQL, zijn sommigen misschien op zoek naar een hulpmiddel om het hele proces eenvoudiger te maken.
In deze serie gaan we een hulpprogramma bekijken dat dat wel doet net dat, maar voordat we dat doen, laten we een snelle inleiding hebben in de WordPress-database om ervoor te zorgen dat we allemaal op dezelfde pagina staan.
Als het gaat om het bespreken van de WordPress-database, kan een hele reeks artikelen worden geschreven over elke tabel, elke kolom, het schema, hoe u optimale query's schrijft, enzovoort.
Dit is niet de serie daarvoor.
In plaats daarvan gaan we in dit artikel twee dingen doen:
Uiteindelijk zou dit een deel van het onderliggende werk moeten helpen uitleggen of demystificeren voor diegenen die meer tijd aan de front-end besteden, en het kan diegenen helpen die meer tijd doorbrengen op de applicatielaag die met de WordPress API werkt, begrijpen welke functies overeenkomen met welke tabel (wat uiteindelijk kan leiden tot het schrijven van betere code).
Over het algemeen denk ik dat de meerderheid van de lezers van Wptuts + weet wat een database is.
Rechtstreeks uit Wikipedia:
Een database is een georganiseerde verzameling gegevens. De gegevens zijn meestal georganiseerd om relevante aspecten van de werkelijkheid te modelleren (bijvoorbeeld de beschikbaarheid van kamers in hotels), op een manier die processen ondersteunt die deze informatie vereisen (bijvoorbeeld het vinden van een hotel met vacatures)..
Dat is een goede definitie, maar ik vind het niet zo'n goed werk om de WordPress-database of soortgelijke webtoepassingen te illustreren - het is een beetje te algemeen. Dus laten we van hieruit onze eigen werkdefinitie maken die we in de rest van de serie kunnen gebruiken.
Laten we dit proberen:
Een database bestaat uit minstens één tabel. Een tabel bestaat uit rijen en kolommen die elk unieke stukjes informatie opslaan. Elke rij wordt een record genoemd. Meerdere tabellen kunnen in een database bestaan en soms kunnen tabellen aan elkaar gerelateerd zijn.
Het meest verwarrende deel van wat ik hierboven heb gedeeld, is misschien dat tabellen met elkaar te maken kunnen hebben. We zullen dit idee opnieuw bekijken voor het einde van het artikel - maar laten we eerst de WordPress-database bespreken.
Kort gezegd, de WordPress-database bestaat uit elf tabellen (tenzij u Multisite gebruikt, maar dat valt buiten het bereik van deze reeks).
Nu heeft elke tabel zijn eigen reeks kolommen die een verscheidenheid aan informatie vertegenwoordigen die is opgeslagen in de tabel. Bijvoorbeeld de wp_posts tabel heeft een kolom genaamd POST_CONTENT die de feitelijke inhoud vertegenwoordigt die in een bericht is opgeslagen.
De tabellen en hun beschrijvingen zijn als volgt:
En dat is alles wat er is in de WordPress-database. Het is relatief eenvoudig en recht toe recht aan?
Posts worden bewaard in de posts-tabel, opmerkingen in de tabel met opmerkingen, Gebruikers in de tabel met gebruikers, enzovoort. Natuurlijk zijn er subtiele nuances (zoals het feit dat Pages in de tabel Posts zijn opgeslagen); het is echter een relatief ongecompliceerd schema om te volgen.
Dat is een goed ding.
Herinner je ook hoe we eerder vermeldden dat sommige tabellen naar elkaar kunnen verwijzen? Een goed voorbeeld hiervan is de tabel met opmerkingen en de tabel met berichten. Aangezien er opmerkingen worden achtergelaten in een specifieke post, moet een opmerking weten met welke post-ID deze is geassocieerd, zodat wanneer een post is geladen, opmerkingen over de ID van die post kunnen worden opgehaald.
Hoe dan ook, dit is meer detail dan waar we in deze serie duiken, maar hopelijk is het genoeg om je een idee te geven. Als u geïnteresseerd bent in meer technische informatie, de relaties tussen de tabellen, de kolommen en meer, check dan zeker het WordPress Codex-artikel in de databasebeschrijving.
Op dit punt hebben we alles besproken wat we nodig hebben in onze inleiding van de WordPress-database. Hopelijk helpt dit om het gordijn open te trekken voor wat zich onder de kapel afspeelt als je informatie opslaat in WordPress, maar nu dit besproken is, is het tijd om te kijken naar een tool die het werken met datamigraties uiterst eenvoudig maakt.
En aangezien we nu begrijpen hoe de database is georganiseerd, moeten we ook inzicht hebben in de manier waarop migraties werken.
Accentsconagua