Website in opbouw

Status
Niet open voor verdere reacties.
Nee, geen koppeltabel.

Backend: hierin kan je 2 dingen doen (hiervoor een stukje php schrijven)
- woorden uit de tTags tabel kiezen en toevoegen aan veld tags.
- woorden verwijderen uit veld tags.
Performance is niet belangrijk omdat je dit als enige doet.

Frontend: de website bezoeker filtert op veld "tags" (zie query hierboven)
Performance is wel belangrijk en dat lukt prima met de WHERE query.
 
Je bedoelt alle tags in één veld van Tbestand?

Zo ja, dan gaat dat vermoedelijk problemen geven omdat een trefwoordenregister in een goed studieboek
soms wel een paar honderd trefwoorden kan bevatten.
 
En dan komt databasenormalisatie weer om de hoek kijken. Elke tag in een apart record.
 
Ja, dat kan je dan inderdaad doen. Zo kan een bepaald trefwoord aan meerde dingen worden gekoppeld.
 
Bedankt.
Ik denk dan ook een kolom toe te voegen om de trefwoorden te kunnen groeperen
op de manier waar ik eerder de filters voor wilde gebruiken.
Die trefwoorden zou men dan bijv. uit een dropdownlist kunnen selecteren, terwijl de andere trefwoorden
dan misschien via woordsuggesties getoond kunnen worden.
 
pieter53 zei:
Maar om weer even op het filter en trefwoorden idee terug te komen.

Waarom trefwoorden?
Stel je hebt een aantal bestanden die het binnenvaart weekblad Schuttevaer bevatten.
Laat je nu op die bestanden een zoekopdracht "dieselmotor" los dan sneeuwt dat ene artikel over nieuwe ontwikkelingen in zake dieselmotoren volledig onder door advertenties of verhaaltjes over schepen met dieselmotoren en advertenties van dieselmotoren te koop.
Reken maar dat dat er heel wat zijn.
Door nu een trefwoord "dieselmotor" alleen te hechten een editie met nuttige informatie bereikt men sneller een beter resultaat.

Dan het probleem met filters, categorieën, groepen of hoe men het maar noemen wilt.
Ik ben er nog niet uit.
Je zou na een hoofdindeling
Zeevaart
Kustvaart
Binnenvaart
Voor elk van deze groepen zou men misschien nog een verdere verdeling kunnen maken in de trant van
- vrachtvaart
- passagiersvaart
- veer- en lijndiensten
- pleziervaart
- overige vaartuigen
- infrastructuur
- navigatie
- voortstuwing
- scheepsbouw
- voorschriften
- overigen
en dan ben je er waarschijnlijk nog niet want veel van de categorieën zijn nog te weinig precies.
Bij de meeste van de genoemde vaartuigen vormen de onderdelen een verhaal apart en
ook zou ik roeien en zeilen niet in de zelfde groep onder willen brengen als een de stoomturbine of een moderne hybride aandrijving.
Er kan wel aardig wat met trefwoorden uitgefilterd worden, maar het moet allemaal een beetje overzichtelijk blijven en intuïtief werken.
Kortom: dat wordt nog even puzzelen.
Klik om te vergroten...
Het leuke is dat je met mijn opzet oneindig veel groepen, sub-groepen, sub-subgroepen etc kan maken.
Dus een item kan ook in meerdere groepen zitten.

Ik snap alleen niet waarom het nu over tags gaat, terwijl het net over filters ging. Tags en filters zijn in mijn beleving twee verschillende dingen.
 
Misschien ben ik niet zo goed thuis in deze terminologie.
Maar het verschil tussen een filter en een trefwoord ligt volgens mij meer aan hoe je het woord gebruikt.

In veel gevallen zal het zo zijn dat als je een tweede trefwoord toevoegt aan je zoekopdracht; het aantal treffers vermindert.
Wanneer het tweede trefwoord nu een ruim begrip is, dan zou men volgens mij van een filter kunnen spreken.
Als je eerste trefwoord "schip" is, dan werken woorden als "zeevaart", "binnenvaart", "pleziervaart" volgens mij dus als een filter,
maar het zijn net zo goed ook trefwoorden.
 
Ja, en die kan je prima in mijn voorbeeld verwerken. Ik zou zeggen: Probeer het eens.

Ergens moet je beginnen ;-)
 
Doen we!

Wat raad jij eigenlijk aan als je een nieuwe database aan wilt maken.
Dat met SQL doen of de meer graphische methode van MyPhpAdmin gebruiken?
(Het zou natuurlijk niets uit moeten maken, maar misschien is het één toch fout-gevoeliger, dan de ander)
 
Het resultaat is hetzelfde of je via de commandline in staat in te kloppen, of grafisch werkt. Maar ik werk altijd op de grafische wijze. Weinig phpMyAdmin maar wel HeidiSQL. Dit is een programma en geen web-app.

Als ik voor mijn site wat moet aanpassen maak ik vaak een SQL-file lokaal op mijn ontwikkel omgeving, en voer deze meestal via SQL in de commandine uit. Dan heb je nooit last van timeouts van je webserver.

De database maak ik altijd via het Direct Admin hostingpanel aan.
 
Laatst bewerkt:
Je bedoelt alle tags in één veld van Tbestand?

Zo ja, dan gaat dat vermoedelijk problemen geven omdat een trefwoordenregister in een goed studieboek
soms wel een paar honderd trefwoorden kan bevatten.
Klik om te vergroten...

Ik zal jouw vergelijking gebruiken.

tabel tBestand: extra veld "trefwoorden" (tags) die bij het onderwerp (bij het record) horoen, ofwel het filter veld.
tabel tTrefwoorden: het id veld gebruik je niet. het trefwoord veld gebruik je zonder koppeling/koppeltabel.

Het trefwoordenregister: dit is tabel tTrefwoorden en die mag gerust duizenden records bevatten (het is een tabel).
Het veld trefwoorden (in tBestand): hier staan misschien 10 a 20 trefwoorden per record in, ook dat is geen probleem.
Het zoekfilter: de bezoeker zoekt (via jouw query) in veld trefwoorden van tabel tBestand.

Vanuit database ontwerp is dit geen nette oplossing maar het is simpel, makkelijk en doeltreffend.

In de backend:
- is een stukje php nodig om trefwoorden (de tags) bij een record in tBestand toe te voegen of te verwijderen.
- is voor consistentie een stukje php nodig dat als je iets verandert in tabel tTrefwoorden dat dit ook wordt verandert in veld trefwoorden van tabel tBestand.

Kijk even bij
- deze backend van een webshop (veld Producct Tags) dat is wat ik bedoel.
- of bij StackOverflow, de tags staan onder de vraag. Deze tags (categorieën) worden als zoekfilter gebruikt in het zoekveld. De tags liggen vast in een tabel.

SO.jpg
 
Laatst bewerkt:
Ik geloof dat dit een iets minder handige oplossing is (maar met mijn geringe ervaring kan ik me daar natuurlijk in vergissen).

Ik heb een boek met de titel: "Terminologie van Riviervissers in Nederland" dat heeft een trefwoorden-index met circa 1900 vermeldingen.
Het boek "Verdwenen schepen" stelt zich met een trefwoorden register van ca. 1000 tevreden.
Binnenvaarttaal zelf heeft meer dan 20.000 termen, maar die komen gelukkig niet allemaal als trefwoord in aanmerking.
Toch lijkt het me wel verstandig dat soort zaken in het achterhoofd te houden.
 
Een tabel tTrefwoorden met 25.000 records is geen probleem.

Het gaat er meer om hoeveel trefwoorden je bij een onderwerp wilt zetten.
Als dat er heel veel zijn dan werkt mijn oplossing niet.
Als het er een stuk of 20 zijn bij 1 record in tabel tBestand dan werkt het wel.
 
Goed dat te weten.
Tja, het is niet echt mijn bedoeling duizenden trefwoorden aan 1 bestand te koppelen, maar je kan niet weten....
Ik denk er over na.
 
Voor een onervaren iemand als ik bleek het toch handiger om geen - of _ in de database te gebruiken.
Ik weet dat het gebruik daarvan geen beletsel hoeft te vormen, maar als je tegen de zeventig loopt
bega je makkelijk een vergissing en af en toe vergeet je wel eens wat.

Aangezien meerdere titels bij één schrijver kunnen horen, maar ook dat één titel meerdere schrijvers kan hebben
leek mij een koppeltabel tussen titels en schrijvers het handigste.
Het schema komt er dan zo uit te zien.

schema vraagbaak3.jpg

Nu komt voor mij natuurlijk de vraag hoe krijg je de gegevens uit de database.
Nu stond op stackoverflow.com/questions/7364969/how-to-filter-sql-results-in-a-has-many-through-relation een mooie lijst van queries.
Nr 5. was voor mij het meest overzichtelijk en ook het best te begrijpen.

Maar misschien heeft men hier betere suggesties?
 
De kans is klein maar het zou kunnen gebeuren

Schrijver 1 = Piet Jansen
Schrijver 2 = Piet Jansen

Ze geven beide in april 2022 een boek uit met titel "De binnenscheepvaart"
Gaat dit goed in het data ontwerp? En in het filter?
 
Ik denk dat de kans inderdaad klein is, maar er zijn 3 mogelijkheden omdat op te lossen.
1. je gebruikt een toevoeging bij de naam. Op de klassieke wijze bijv. Jansz. of het geboorte jaar
2. je kan het in de omschrijving van het boek gebruiken (dat zal je ook moeten doen voor gewijzigde herdrukken)
3. er is een extra veld 'note' beschikbaar.

Het is trouwens niet bedoeling dat het zoeksysteem één bepaald boek vindt;
het is de bedoeling dat er een aantal 'werken' die een bepaald aspect behandelen gevonden worden
en dat men aan de hand van de omschrijving de meest 'biedende(n)' uitkiest.
 
Einde van dit topic. Verschillende vragen graag in een eigen topic.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan