database design for hastighed

Ja. Goer det den traditionelle maade.

Databaser er optimeret til at lave joins mellem tabeller.

Hvis du er til daarlig performance og ulaeselig kode saa er tricket nok:

... WHERE CONCAT(',' , felt , ',') LIKE CONCAT('%,', detdulederefter, ',%')

Okay, jeg vil gætte på du har ret, men når nu der kommer 500.000 kunder og hver kunde har 5 ekstra felter, bliver søgningen ikke langsommere når der 2,5 millioner records istedet for 500.000 ? Synes egentlig det var mere overskueligt på min måde, fortæl mig hvorfor jeg tager fej, jeg forstår det ikke helt.

Hvis du laver de rigtige index, saa den join hurtig.

Jeg vil snarere tro at test paa om en streng indeholder vil koere meget langsom fordi den kan ikke udnyttet index.

okay, det tænkte jeg nok. det er så nu jeg skal lære at bruge indexer. jeg har en slags fobi mod at læse om det fordi det lyder så ekstremt kedeligt, så hvis du giver mig sql sætningen til at lave indexet helt kort i denne situation er pointene dine.

Det er nu ikke saa vanskeligt.

Lav dine SQL saetninger.

Find alle de felter som bliver brugt til = test og put index paa dem.

Det rammer du 80% rigtigt med.

De sidste 20% skal du saa laese dig lidt til.

select * from tExtraInfo where infoID=[infoID] and text like "%[text]%"

select * from tExtraInfo where kundeID=[kundeID]

Der er der saa ingen join.

Men bare de to queries siger index paa:

tExtraInfo.infoID
tExtraInfo.kundeID

okay den her kan laves med en join, ikke ?

select k.*, ei.text from kunde k, tExtraInfo ei where k.id=ei.kundeID

F.eks. ja.

kunde.id
tEkstraINfo.kundeID

skal have index for at denen fungerer godt.

Nu går jeg ud fra at det er en MySQL database du har, og MySQL tilbyder desværre ikke så mange forskellige index muligheder, som f.eks. PostgreSQL, men der er stadig muligheder for at optimere databasen og motoren bag den.

Men kig også på din SQL queries, da de har en stor del af performancen med også, og søg evt. på brugen af Denormalization hvis du har mange og/eller store JOIN queries. Her kan du også hente en del performance, også selvom du bruger lidt længere tid på at duplikere data i flere tabeller er trade-off'et langt bedre i mange join tilfælde.

Og så skal du kigge på dine queries om det er range, point, multipoint, etc. og om der bliver brugt nogle af de mere tunge funktioner som Distinct og Group By, som også fortjener ekstra behandling. Og tænk over på hvad koden kan gøre for dig og hvad databasen skal gøre for dig og hvad de i fællesskab skal gøre.

Jeg forsøger at holde mig til helt simpel mysql da jeg muligvis skal  migrere til mssql senere. Det er derfor jeg helst vil joine og sortere i koden, plus jeg er bedst at til kode i forhold til db optimering. Indtil videre går det lynhurtigt med 20 brugere og 30000 kundeemner. public2, vil du også mene jeg skal droppe den metode jeg har beskrevet i første indlæg ? kommer søgningen med den metode til at være for langsom når der er 500.000 kundeemner ?

Join er rimelig portabel mellem databaser. Portabilitet er ikke en god unskyldning for at undgå joins.

Denormalisering bruges en gang imellem i den virkelige verden.

Men vent med at bruge det som optimerings metode indtil du har haft 5 års fuldtids arbejde med databaser.

Jeg vil nu sige, at jeg ikke har arbejdet 5 års fuldtid med databaser, men jeg bruger og har brugt denormalisering ganske fornuftigt og alt efter opgaven, også ganske ofte til at optimere min performance.

Jeg arbejder med databaser i kraft af mit studie, men går ikke ud fra at det er hvad du tænker på. Men selvfølgelig er der altid plads til at blive bedre og gøre det bedre.

Hvis man skal lave 1000 tabeller så vil der måske være:
- 800 tabeller uden performance problemer
- 190 tabeller hvor man skal optimere index for at få passende performance
- 9 tabeller hvor man skal bruge et materialized view for at få passende performance
- 1 tabel hvor man skal denormalisere for at få passende performance

Og det ene tilfælde vil altid være denormalisering på M siden og ikke som i dette tilfælde her på 1 siden.

På 1 siden giver det en liste af værdier i en kolonne og det vil ikke forbedre performance men derimod totalt dræbe performance.

Jeg prøvede at lave en lille test med 10000 korte række med 10 rækker i en anden tabel tilknytet versus 10000 lidt længere rækker og søge på de id'er som er PK versus konkataneteret. Java og MySQL.

Den normaliserede udgave var næsten 300 gange (ikke 300% men 300 gange) hurtigere.

mousedreamer?

okay, så vidt jeg forstår, så er denormalisering det jeg har gang i. Det er simpelthen nemmere for mig at kode. Men jeg forstår godt for- og bagdelene nu. Læg et svar.

Hvis det du har gang i er flere værdier kommasepareret i samme felt, så er der ingen fordele!

:-)

Og et svar fra mig.