Als ik een reeks tags toevoeg aan een artikel dan doe ik dat komma-gescheiden:
Appel, banaan, cocosnoot
Echter als ik deze tags wijzig in mijn admin-backend, dan moeten ze weer exact zo in de koppeltabel in mijn database staan.
Dus als ik een tag verwijder, en een tag toevoeg, of een tag aanpas dan moeten deze mutaties ook uitgevoerd worden. Dus als ik "Appels, banaan, cokosnoot, dadel" invoer, moet deze met hun ID's in de databse komen, en de Id van 'cocosnoot' moet dus uit de koppeltabel worden verwijderd.
Nu kan je al deze mutaties in een functie uitvoeren, maar je kan ook gewoon alle ID's in de koppeltabel verwijderen, en de nieuwe ID's weer erin zetten.
Even voor de goede orde:
- keywords_items is je koppeltabel?
- keywords_items.TagID verwijst naar je Keywords.ID?
- ItemType is een stukje extra info mbt het item (waarom niet opslaan bij het item zelf; klinkt alsof ie hier nu voor elk keyword gelijk is)?
Zolang je in je koppeltabel geen eigen (primary) key hebt houd ik altijd wel van "weggooien en opnieuw beginnen". Dat is gewoon het eenvoudigst (even in een transactie inpakken voor het geval d'r ergens iets fout gaat).
Met eigen key wil je deze natuurlijk behouden (ivm externe relaties - dat is meestal de reden voor zo'n key). Dan insert ik meestal eerst de ingegeven keys (of update voor bestaande key), en gooi daarna alles weg wat in de database nog wel aan het "item" is gekoppeld, maar niet meer in de huidige ingegeven lijst met "keywords" zit.
Even voor de goede orde:
- keywords_items is je koppeltabel?
- keywords_items.TagID verwijst naar je Keywords.ID?
- ItemType is een stukje extra info mbt het item (waarom niet opslaan bij het item zelf; klinkt alsof ie hier nu voor elk keyword gelijk is)?
Correct! En over ItemType. Een tag kan je koppelen aan ItemID's van diverse soorten content, en die hebben een eigen tabel. Maar daar gaat de vraag niet over.
Dus jij zegt gewoon: Gooi alles uit de koppeltabel weg wat bij dat ItemID hoort en voeg de keywordID's opnieuw toe, in plaats van vergelijk alles van wat er bij het ItemID in de koppeltabel hoort en maak ze gelijk ze met wat er in de invoer is ingevuld?
Ja, maar dat is mijn 2ct. Geen idee of dat "best practice is". Ik ben meestal vrij praktisch, en niet heel erg theoretisch.
Maar toch nog even over dat ItemType: Dat is dus wel iets wat je bij het opslaan van de keywords "bij de hand" hebt (dus ook opnieuw in kunt vullen nadat je alle info hebt weggegooid)?
- Ja: mooi, dan kun je idd alles weggooien (maar het is dan dus voor elke tag voor dit specifieke item gelijk - raarrr?)
- Nee: dan zul je toch de boel moeten behouden en dus inderdaad gaan onthouden welke koppelingen je wilt behouden/bijwerken, en welke je weg kunt gooien (= meer gedoe).
Ja, die ItemType geeft aan of de keywords bij video's, nieuws of uploads horen. En dat kunnen soms overlappende ID's zijn. En ik ga nu even niet de moeite nemen om dat te corrigeren hiervoor ;-)
Je kunt cocosnoot toch niet zonder meer uit de koppeltabel weggooien omdat deze mogelijk aan meerdere items is gekoppeld? Sterker nog, het enige wat dan in principe verandert als je hier cokosnoot van maakt is een verandering van het keyword wat je gewoon in een aparte operatie zou kunnen regelen? Dit label staat in principe verder los van de koppelingen met dit label, deze heeft in zekere zin geen "betekenis", het is slechts een label.
Een mogelijke oplossing is wellicht een wat intelligenter formulierveld voor tags, bijvoorbeeld een soort van samengesteld autocomplete veld, op eenzelfde wijze als bij GMail bijvoorbeeld, waarin je adressen van ontvangers kunt typen die automatisch worden aangevuld met behulp van gegevens uit een adresboek. Dit garandeert dat je bestaande tags kunt (her)gebruiken. Je kunt er dan nog voor kiezen of dat de plaats is om nieuwe tags toe te voegen, of dat je dat op een andere plaats doet uit oogpunt van beheer, anders ontstaat er wellicht een wildgroei aan tags, afhankelijk van het aantal personen die dit soort artikelen klopt.
En als je de labels inhoudelijk wilt aanpassen zou je dat in een aparte backend kunnen doen.
Ook zou je deze nog uit kunnen breiden en hier een soort van taxonomie van kunnen maken. Zodat je dezelfde woorden ook in verschillende contexten zou terug kunnen laten komen.
Het laatste wat je wilt bij keywords/tags is een trits aan synoniemen die in feite hetzelfde zeggen (wildgroei). Het uiteindelijk doel zal mede het terugvinden van informatie op grond van dat soort tags zijn neem ik aan? Dan moet je je tags wel een beetje onderhouden en snoeien uiteraard.
Een autocomplete heb ik er al inzitten. Maar dat verhindert niet 100% dat er verkeerde tags worden ingevoerd. Verder heb ik wel eens nagedacht aan een synoniemen-tabel. Maar ik denk dat het eigenlijk al onnodig is vanwege de autocomplete, en een aparte backend om de keyword/tags te kunnen wissen of om te zetten naar een ander keyword/tag.
Maar goed, het gaat mij niet zozeer om de synoniemen, maar de mutaties als er iets wordt aangepast, toegevoegd of verwijderd. De invoer moet gelijk komen te liggen met wat er in de database staat. Het voorbeeld cocosnoot v.s. cokosnoot was meer bedoeld als opzettelijke typfout die je kan corrigeren dan als synoniem. ;-)
Ik denk er zelf aan om de boel eerst gewoon met een query uit de koppeltabel te wissen bij de ItemID en het type, en dan opnieuw toe te voegen. Het is wel de simpelste methode. Of kent iemand nog een goede procedure om deze mutaties uit te voeren om de koppelingen in de database gelijk te houden met de invoer?
