arrays en sql

[wboard]

Hey,

Ik zat me ff te bedenken, als je een ratingsysteempje hebt..
Dan sla je het userid van de stemmer op in een database.
Maar als je nu een userdb van 10000 users hebt en je wilt registreren wie er al gerate heeft. En je hebt bijvoorbeeld 100 dingen om te raten. Dan krijg je een db met 10000*100 = heelveel items.
Zou het misschien kunnen dat je de gebruikers die gerate hebben, in een array gooit en dan dat je die array in je database zet, dan heb je maar 100 items

Is daar soms een manier voor?

[.oisyn]

of andersom: ipv per rating een array met users, per users een array met de ratings die ze gedaan hebben

maar in principe moet het niets uitmaken, de vorm van je database verandert alleen, de oppervlakte niet

met vorm bedoel ik natuurlijk de structuur kwa kolommen/rijen. Bij een array met users krijg je niet veel rijen, maar je kolommen zijn wel heel lang. Bij een array met ratings krijg je veel rijen, en je kolommen zijn relatief kort
Maar de grootte van je database, de oppervlakte dus, blijft even groot.

[ Voor 43% gewijzigd door .oisyn op 13-03-2003 15:14 ]

[Freee!!]

Wat jij wil is misschien gedeeltelijk mogelijk. Je moet rekening houden met het feit dat het aantal kolommen in een database niet echt makkelijk is uit te breiden, maar het aantal rijen wel. Als het aantal te raten items een beetje constant is en het aantal gebruikers variabel (vrij normale situatie), dan zou je jouw array kunnen kantelen en als SQL tabel op kunnen slaan. Je houdt nog 10000 rijen over met iets meer dan 100 kolommen^*, maar dat is te behappen.

^*Je moet ook gebruikers-ID e.d. opslaan.

[djluc]

Niet doen, wat je van plan bent is een fout in je db-ontwerp. Probeer het alstublieft niet, je kunt hier een hoop topics over vinden, denk aan normalisatie ed.

[ Voor 2% gewijzigd door djluc op 13-03-2003 15:18 . Reden: typo ]

[.oisyn]

Over het algemeen werkt een koppeltabel toch wel het beste, dus gewoon een tabel met 2 kolommen: user_id en rating_id, waarin je de user-rating combinaties zet

[whoami]

Arrays in databases..... Bah. De laatste tijd komen hier nogal dergelijke topics langs, en iedere keer weer is de conclusie dat dit een slecht db ontwerp is.

Trouwens, wat zijn 1000000 records nou in een ganse database. Peanuts.

[Sn3akz]

whoami schreef op 13 March 2003 @ 15:20:
Arrays in databases..... Bah. De laatste tijd komen hier nogal dergelijke topics langs, en iedere keer weer is de conclusie dat dit een slecht db ontwerp is.

Trouwens, wat zijn 1000000 records nou in een ganse database. Peanuts.

Mee eens

MySQL is speciaal ontworpen zelfs voor grote hoeveelheden records (5 miljoen ofzo?) iig valt het wel mee hoor.. 1 miljoen records

[ACM]

wboard schreef op 13 March 2003 @ 15:10:
Maar als je nu een userdb van 10000 users hebt en je wilt registreren wie er al gerate heeft. En je hebt bijvoorbeeld 100 dingen om te raten. Dan krijg je een db met 10000*100 = heelveel items.

Maar HEB je ook 10000 gebruikers en 100 items om te raten?
En dan nog, dat is 1.000.000x een paar integers, zo veel is dat nou ook weer niet.

Zou het misschien kunnen dat je de gebruikers die gerate hebben, in een array gooit en dan dat je die array in je database zet, dan heb je maar 100 items

Je wilt 100 arrays met 10000 posities maken in je DB?
En wat als er een gebruiker bijkomt? Ga je dan de array eruit halen, die user erbij en opnieuw opslaan?

Sn3akz schreef op 13 March 2003 @ 15:24:
MySQL is speciaal ontworpen zelfs voor grote hoeveelheden records (5 miljoen ofzo?) iig valt het wel mee hoor.. 1 miljoen records

Mysq is daar bij mijn weten niet voor ontworpen. Het is er wel geschikt voor, maar minder goed dan de echte grote database paketten. Die juist pas bij dat soort getallen hun echte kracht laten zien

[bille]

je kan je ook afvragen of je wel wilt weten of wie al welk item gerate heeft.. ipv wat de gemiddelde rating is..

overgens kan een tabel met 1 miljoen records best.. als je maar goede indexes hebt en geen String kolommen als primary keys hebt gezet, maar daar zijn gewoon performance regels voor.

[.oisyn]

je kan ook gewoon 1 tabel maken met 1 kolom en 1 rij, wat gewoon een BLOB is, en dan zet je die 100*10000 array omgezet naar binary in deze blob

(klinkt stom he? toch is het niet zoveel anders dan jouw eigen voorstel )

[whoami]

.oisyn schreef op 13 March 2003 @ 15:32:
je kan ook gewoon 1 tabel maken met 1 kolom en 1 rij, wat gewoon een BLOB is, en dan zet je die 100*10000 array omgezet naar binary in deze blob

(klinkt stom he? toch is het niet zoveel anders dan jouw eigen voorstel )

Waarom dan niet 1 textfile gebruiken?

[.oisyn]

ja maar dan gebruik je geen database meer, en dus is het slecht

[wboard]

textfiles zuigen..., moet je hem uitlezen, de data splitsen en dan nog gaan checken of de waarde er wel of niet in staat. Misschien nog in een array poten, kortom klote

[whoami]

wboard schreef op 13 March 2003 @ 15:38:
textfiles zuigen..., moet je hem uitlezen, de data splitsen en dan nog gaan checken of de waarde er wel of niet in staat. Misschien nog in een array poten, kortom klote

Hmm... M'n reply was dan ook sarcastisch bedoeld.

[Verwijderd]

Wat jij voorstelt lijkt meer op een multiedimensionele database !

Dit heeft niets te maken met SQL.

Welke database gebruik je / wil je gebruiken ?

[ACM]

bille schreef op 13 March 2003 @ 15:30:
overgens kan een tabel met 1 miljoen records best.. als je maar goede indexes hebt en geen String kolommen als primary keys hebt gezet, maar daar zijn gewoon performance regels voor.

Met goede indices maakt het in principe weinig uit of je nou een string of een getal als primary key gebruikt.
Het maakt natuurlijk wel iets uit een integer vergelijking is een stukje goedkoper dan een stringvergelijking, maar met een goede index zijn het (als het goed is ) vrij weinig vergelijkingen.

[wboard]

mysql