Invoer gelijk houden met database
Ik heb op mijn site keywords (tags) bij artikelen staan, en ik wil dat de invoer hiervan gelijk loopt met de database.
Mijn opzet is als volgt:
Tabel: Keywords
- ID (PK)
- Keyword (VARCHAR)
Tabel: keywords_items
- ItemID
- TagID
- ItemType (kan zijn news, video, upload)
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.
Wat is 'the best practice'?
Gewijzigd op 03/02/2018 13:00:51 door - Ariën -
https://stackoverflow.com/questions/3974671/best-way-to-store-and-retrieve-synonyms-in-database-mysql
Gewijzigd op 03/02/2018 16:23:13 door - Ariën -
- 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.
Rob Doemaarwat op 03/02/2018 16:30:59:
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)?
- 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?
Gewijzigd op 03/02/2018 17:03:54 door - Ariën -
- Ariën - op 03/02/2018 17:03:05:
Dus jij zegt gewoon ...
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).
Gewijzigd op 03/02/2018 17:24:34 door Rob Doemaarwat
Gewijzigd op 03/02/2018 17:59:53 door - Ariën -
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.
Thomas van den Heuvel op 03/02/2018 22:54:49:
Je kunt cocosnoot toch niet zonder meer uit de koppeltabel weggooien omdat deze mogelijk aan meerdere items is gekoppeld?
Nee, niet alle cocosnoten, alleen die voor dit item. Dus andersom: alle keyword_items voor het onderhavige ItemID weggooien.
Als "cokosnoot" (met een k) dan nog niet in Keywords staat deze eerst toevoegen, en dan het (Tag)ID in de koppeltabel invoegen voor dit ItemID.
Dan heb je dus wel "cocosnoot" als tag voor alle andere artikelen, en voor dit artikel "cokosnoot" (met een k). Niet zo heel netjes qua beheer.
Of snap ik het nou niet, en hadden alle bestaande "cocosnoten" omgehangen moeten worden naar "cokosnoot" (of dus enkel Keywords.Keyword bijgewerkt)?
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?
Gewijzigd op 03/02/2018 23:33:15 door - Ariën -
Die wijzigingen (weggooien en toevoegen, alsmede wellicht wijzigingen in het item zelf) wil je trouwens wel als één ondeelbare actie uitvoeren, en daarvoor bestaan weer (database)transacties.
Dus het wordt zoiets als:
Code (php)
1
2
3
4
5
2
3
4
5
start transactie
verwijder tags gekoppeld aan item
voeg mogelijk nieuwe/andere tags toe aan item
voer wijzigingen door in item zelf
commit transactie
verwijder tags gekoppeld aan item
voeg mogelijk nieuwe/andere tags toe aan item
voer wijzigingen door in item zelf
commit transactie
Gewijzigd op 04/02/2018 01:41:20 door Thomas van den Heuvel