Ik vroeg me het volgende af: wanneer je een blog hebt, met lange verhalen, wat is dan de beste keuze:
- 1 - Je maakt 1 tabel met titels, en 1 tabel met de verhalen, dan moet je niet in de verhaaltabel zoeken als je enkel de titels wil weergeven
- 2 - Je maakt 1 tabel met de titels en de verhalen samen (Als je enkel de titels wil, gebruik je uiteraard enkel een select op dat veld, en géén *)
Mij lijkt optie 1 sneller te werken dan 2, alleen krijg ik het niet getest.
Volgens mij is 2 toch sneller. Wanneer je namelijk 1 artikel met verhaal wilt tonen, heb je bij 2 maar 1 tabel en dus 1 lookup nodig terwijl je bij 1 wel 2 maal een zoekactie moet starten.
Verder denk ik dat databases tegenwoordig wel zo uitgewoond uitgebouwd zijn dat hij, wanneer je een index zet op de titels zet, hij alleen alle data uit die view zal trekken en niet naar de inhoud van de tabel zelf zal hoeven gaan.
En als laatste: weegt de winst die je ermee krijgt (als er al winst is) op tegen de moeite die je erbij nodig hebt om de twee tabellen allebei goed te beheren?
De enige situatie waar ik me kan voorstellen dat je 1 object over meerdere tabellen wilt verdelen is wanneer een deel van het object veel schrijf-acties ondervindt, en een ander deel waar veel lees-acties op los worden gelaten zelden verandert. De schrijf-acties zouden anders constant de indexes die voor de leesacties zo handig zijn doen verversen. Scheidt je de twee, dan kan je denk ik toch een aantal indexes die anders opnieuw opgebouwd zouden worden met rust laten.
Het is toch een 1-op-1 relatie? Dan krijg je automatisch maar 1 tabel, dus waarom jij 2 tabellen zou willen aanmaken, geen idee. Wanneer jij een titel opvraagt, zal de database niets merken van het feit dat er ook nog andere data in deze tabel staat.
In jouw voorbeeld vergeet je de belangrijkste query, de query waarbij je zowel de titel als het verhaal nodig hebt. En die zal bij optie 1 echt langzamer zijn, er moeten 2 tabellen worden doorzocht. Het zal niet veel verschil maken, op een foreign key zit tenslotte een index, maar toch. Daarnaast moet je een goed datamodel gaan omzetten naar een rottig datamodel, dat is zonde van de tijd.
Gebruik EXPLAIN om te achterhalen hoe de database jouw queries uitvoert en welke indexen worden gebruikt.
SELECT
titel,
bericht
FROM
tabelnaam
WHERE
id = 2;
?
1 query om alle benodigde gegevens van het record met id 2 op te halen. Ik heb geen flauw idee waarom je daar 2 queries voor nodig zou hebben of eerst alle data moet ophalen en dan in PHP gaan uitvogelen waar id nr. 2 is gebleven.
Heb je al wel een beginners tutorial SQL doorgenomen? Lijkt het niet op, begin daar eerst maar eens aan.
Stel: de titels weergeef ik allemaal als link, en ik wil het verhaal met ID 2.
Jij schreef:
Wat dacht je van:.... ?
Heb je al wel een beginners tutorial SQL doorgenomen? Lijkt het niet op, begin daar eerst maar eens aan.
Ik heb niet de intentie om grof terug te doen, maar als je me kan verklaren hoe ik met jouw query ook alle titels in een link kan stoppen, stuur ik je een vat bier (of whatever) op naar -ik geloof- Brazilië.
Edit:
Ik zal het nogmaals, duidelijk uitleggen.
Stel: Database is als volgt:
- id
- titel
- bericht
Website is als volgt:
- Lijst met alle titels
- Weergave van één bericht
Vraag:
Hoe haal ik het meest efficiënt alle titels op, samen met één volledig bericht.
Ikzelf zie hier twee opties voor:
- 2 queries gebruiken, 1 om alle titels op te halen, 1 om het juiste bericht op te halen
- 1 query gebruiken die alle titels ophaalt, maar dan ook alle berichten mee ophaalt (data te veel dus)
Ik heb sterk de indruk dat dit beter/anders kan, en daarom vraag ik hier hulp.
Jouw eerste vraag kan namelijk 25 miljoen records beslaan, aangenomen dat je zoveel records hebt, en die wil je vast niet in 1x ophalen. Dan zul je met pagination aan de slag moeten (LIMIT en OFFSET). Dat is niet/slecht te combineren met 1 enkel artikel. Die is het meest efficient op te halen met de reeds genoemde query.
En nogmaals, ga eens een beginners tutorial doorlezen. Jouw voorbeelden zijn bijzonder eenvoudig en je kunt ze zelf testen. Even een stopwatch erbij houden en je weet wat sneller is.
Tip: Ga met EXPLAIN achterhalen hoe de query door de database wordt uitgevoerd en welke indexen worden gebruikt. Die bepalen voornamelijk de snelheid. Gewoon EXPLAIN voor je query zetten en uitvoeren in een goede tool. EMS SQL Manager is een aanrader.
