Flere ID's & tags

Dårligt databasedesign.

SELECT * FROM dinTabel WHERE felt LIKE '% 21 %'

Noget a lá det. Men tror nok indexering ryger når man wildcarder på begge sider.

Kan du ændre databasen? For det var da en ganske irriterende struktur. Det er jo komplet umuligt at søge i og databasen fordele er helt omgået når strukturen er sådan - så kan du næsten bruge en almindelig tekstfil lige så "godt".

Men hvis du ikke kan lave strukturen om, så kan du søge efter er regulært udtræk:

For dine tags er det:

SELECT * FROM mytable WHERE mytags RLIKE '(^| )tag3( | $)'

Og for id'erne er det fuldstændig det samme:

SELECT * FROM mytable WHERE myids RLIKE '(^| )21( | $)'

Men igen, det er en umulig struktur at arbejde med og ovenstående vil være meget langsomt - især sammenlignet med alternativet med at have en ekstra tabel til det i stedet.

"et regulært udtryk" skulle det have været - og andre slåfejl ;)

"Men tror nok indexering ryger når man wildcarder på begge sider."
Er ikke med?

Og kan du anbefale andet?
Det går med ikke 10 tabeller, der hedder id1, id2, id3, id4, id5 etc.(det samme med tags).

Hvis jeg var dig ville jeg bygge min database om.
id1 id2 id3  id4
32 242 21 63 532

Men regexp er vist kun på nyuere MySQL, eller er det mig der tänker Oracle

amen - Hvis der er 10 id's, og 10 tag's, og 10 felter til andet info, så synes jeg det bliver for uoverskueligt.

Har i nogen anelse om hvor stor tidforskel der er på at den kigger 10 felter igennem og bruger regexp?

Men det er du nödsaget til hvis du vil udnytte relationsdatabaserne styrke.

Men hvis jeg skal finde alle rækker som har et af følgende id'er:
(1 23 53 432 65 768 223 5 753 21 234 76 23 76 2 32 7868 23 34 34 1 23 53 432 65 768 223 5 753 21 234 76 23 76 2 32 7868 23 34 34 1 23 53 432 65 768 223 5 753 21 234 76 23 76 2 32 7868 23 34 34)

Så er det altså 10 felter den skal søge for 100 forskellige id'er, jeg tvivler altså på at det kan være meget hurtigere en "myids RLIKE '(^| )21( | $)'"
Og er der intet andet end hastighed galt med regexp metoden?

Men du behöver måske ikke at lave så mange kolonner. Nu ved jeg ikke hvad du skal bruge det til og hvordan det ser ud nu. Men du kunne måske bare lave en ny räkke for hver tag, id osv.

Intet andet. Det er en af de väsentligeste ting i en database ;o)

Nu er det fyraften. God weekend ;o)

Altså en tabel der hedder `tags|id` og så smide en række deri hvergang?'
Det går ikke desværre, der vil simpelthen bare blive for mange hvis siden bliver en smule populær.

Er det kun de 2 muligheder der er? Og er hastigheds forskellen virkelig så stor?
Hvis den skal hente 50 rækker ud kan det da ikke være så slemt =/?
Eller lave en COUNT(*) ville det tage sekunder med regexp?

jamen smid lige et svar :)
tak for hjælpen, og barklund med.

Jamen? Tror du det er bedre at have en række med 3 strenge, end at have 10 rækker i tre tabeller? Det er helt forkert! Og optimeringen er gange 100 mindst! MySQL kan klare millionvis af rækker uden problemer på få millisekunder, hvis du bruger databasen rigtigt. At du bliver forvirret er ingen undskyldning for at lave noget bæ.

Du har en tabel med det primære indhold (artikler eller hvad det måtte være) og en anden tabel med tags oig en tredje tabel, der linker tags og artikler. Og tilsvarende for det her andet id (lad os lege, der er id'er over brugere, der abonnerer på artiklerne), så har du en tabel med brugerne og en tabel der kombinerer brugere og artikler.

Og nej, det vil ikke blive for mange. Kommer du over en milliard række skal du begynde at blive nervøs, men ikke et sekund før!

Tricket er jo, at det er lige meget om du skal hente 1 eller 1000 rækker ud. Er der 1000 rækker og du skal søge efter dem, hvor "21" står et bestemt sted i det ene felt, så skal du kigge alle 1000 igennem uanset i hvor mange af dem det står. Og er der 10000 er det helt umuligt. Lav dit design korrekt fra starten og du bliver meget gladere i længden.

Og der er ALT galt med regexp-metoden. Hvis du vil lave sådan noget rod, så kan du næsten lige så godt bruge en tekstfil som sagt. Du får intet ud af databasens regnekraft og muligheder alligevel.

Darn, og nok nødt til at finde ud af hvordan det hele virker :)

"Kommer du over en milliard" - Well det er jo det der skal være muligt, så det hele ikke skulle laves om hvis man kom derop :)

Men smid et svar :)

Nu skal vi også være realistiske. Og hvis du ville komme over en milliard, så ville du i din version være oppe på mange millioner - og så ville din version tage et par dage om at søge efter et tag :)

Og et svar :)

Flere svar!

Well, har valgt at lavet 5 felter til ID's, så må jeg finde ud af hvad jeg gør med tags :)

Ved du hvad sider som youtube, flickr, del.icio etc. gør?
De er jo ret kendte for deres tag-søgning =/

De har selvfølgelig uden tvivl og med garanti en tabel til tags og en tabel der relaterer dem til indholdet. Og ja, de har måske milliarder rækker i tabellen, der kæder indhold sammen med tags, men kommer man op i den størrelse trafik, så er databasestørrelse den mindste bekymring.

Tro mig, at du møder mange andre bekymringer før du rammer loftet for, hvor mange rækker du kan have i databasen.

Jeg kan slet ikke forstå din bekymring eller at du tror, at det er bedre at lave 5 felter. Databasen fylder det samme, men søgning bliver tungere.

Well de 5 felter er ikke til tags, men kategori id's.

Jeg bekymrer mig ikke da jeg ikke regner med at komme derop, men kan bare godt lide at vide hvad jeg laver, og hvorfor jeg ikke gør det på "den anden måde" :)

Men jeg siger tusind tak for hjælpen :D

Og kategorier laves på fuldstændig samme måde - du laver en ekstra tabel :)

Men tak for points anyways :)