Olen lühikeste väljalasketsüklite fänn. Olenevalt projektist on tsükli pikkus erinev, kuid paljude projektitüüpide puhul, millega ma töötan, on minu eesmärgiks kahenädalased väljalasketsüklid.
Lisaks töötan mõnikord mõne projekti kallal, kus keskkonnamuutujad on vajalikud, et kood teaks, kas see töötab arenduses, lavastuses või tootmises.
Ja seda on võimalik saavutada erineval viisil, sõltuvalt projekti vajadustest. Mõnikord töötab konfiguratsioonifail, mõnikord päringu stringi muutujad ja mõnikord on minu arvates mõistlik säte andmebaasi salvestada.
Kuid mis puutub WordPressi, siis arvan, et me teeme paremate disainiotsuste langetamiseks otseteed ja viskame teabe andmebaasi, täpsemalt valikute tabelisse, kui alternatiivid võivad paremini sobida.
WordPressi valikute tabel
Ma tahan olla selge: ma ei arva, et valikute tabel peaks olema seadete prügimäeks, kui teil pole mujale teavet paigutada. Ja see on kogu selle postituse tuum.
Selle asemel võite kasutada:
- konfiguratsioonifail,
- seansi andmed (vajadusel),
- kohandatud andmebaasitabel,
- või midagi muud.
Miks me siis näeme seda nii sageli juhtumas? Asi pole selles, et pole aegu, mil seda oleks mõtet kasutada. Ma lihtsalt arvan, et me kuritarvitame seda. Kuid põhjuseid on.
WordPressi koodeks määratleb sellised valikud:
Valikud on andmetükid, mida WordPress kasutab erinevate eelistuste ja konfiguratsiooniseadete salvestamiseks.
Sellise määratluse abil on lihtne mõista, miks paljud kasutavad seda kohana, kus hoida kõike, mis mujale ei mahu.
Selle asemel arvan, et on oluline esitada küsimus:
Millist tüüpi salvestusruumi jaoks on [need andmed] kõige asjakohasemad?
See tähendab, et kui see on seotud postitustega, siis miks mitte salvestada seda postituse metatabelisse? Sama kehtib terminite metaandmete või kommentaaride või muu kohta.
Asi on selles:
Leidke andmete salvestamiseks kõige loogilisem koht ja asetage need sinna.
Teisisõnu, ärge visake andmeid WordPressi valikute tabelisse, sest need ei mahu kuhugi mujale. See saastab seda. Selle asemel leidke või looge selle jaoks kõige loogilisem koht. See on tõenäoliselt tõend koodilõhnast ja oleks hea põhjus oma koodi arhitektuuri ja teabe esitamise ümberhindamiseks.
Aga kuidas see võib välja näha? See tähendab, kuidas me võtaksime antud koodijupi ja muudaksime selle esitamist andmebaasis.
Kahjuks on raske sellele küsimusele ettekirjutavat lahendust pakkuda, kui probleemi rakendamisel on nii palju variante. Nii et võib-olla on õige juhend:
Kui andmed on seotud juba olemasolevate andmetüüpidega (või tabelitega), siis kasuta neid; muul juhul kaaluge konfiguratsioonifaili või kohandatud andmebaasi tabelit, mis sobib teie tööga.
Olen kindel, et on ka teisi suunavaid tegureid, kuid see on parem koht alustamiseks kui lihtsalt WordPressi valikute tabeli saastamine.