08. september 2009 - 10:11Der er
5 kommentarer og 1 løsning
Dynamiske felter i forbindelse med fleksibel webapplikation
Jeg skal til at lave et produktkatalog, skrevet i PHP. Kodemæssigt har jeg idéerne, men jeg er lidt rådvild hvad angår et optimalt database setup.
Mit produktkatalog skal helst være dynamisk, forstået på den måde at visse felter naturligvis skal være med (varenummer, navn, pris og lignende). Men jeg kunne godt tænke mig at visse felter kunne oprettes dynamisk.
Så forestiller jeg mig en tabel (t2), tilknyttet vareId der kunne se således ud: [code] +--------+------------+------------+ | vareId | feltNavn | feltVaerdi | +--------+------------+------------+ | 2345 | color | Rød | | 5487 | dimensions | 150x230 | | 5487 | weight | 24kg | +--------+------------+------------+ [/code]
Jeg håber også her at ovenstående er til at gennemskue?
Spørgsmålet er så, om ovenstående ville være et optimalt setup? Ville der være et setup der kunne være bedre (jeg tænker især på hastighed og performance ellers) som måske kunne være fleksibelt? Det kunne jo være relevant hvis produktkataloget skulle indeholde trøjer, hvor et dynamisk feltNavn ville kunne være size og så ville en enkelt feltVaerdi jo ikke være særlig fleksibel.
Jeg efterlyser jeres tanker og idéer om ovenstående eller et bedre setup.
#1 Hvis den er korrekt indekseret, vil det naturligvis hjælpe, men jeg har samme idé - at mine queries kan blive voldsomt tunge, hvis datamængden også bliver stor.
Med hensyn til alternativ 1) vil jeg give dig ret i at det er nemt - men så skal jeg bare tilpasse tabellen (samt min kode) for hver gang jeg laver et produktkatalog. Kan det ikke være anderledes, så må det jo være sådan, men det ville være en ubehagelig ting at skulle igennem hver gang.
Angående 2)så ville der i princippet også være et hav af forskellige løsningsmuligheder her. PHP har muligheden for at serialize et array, som jeg så kunne base64 encode og gemme i et felt tilknyttet til vareId. Men så bliver søgemulighederne i produktkataloget (uanset om det er XML eller andet) pludselig også meget mere besværlig - og sandsynligvis også lige så tungt.
Men hvis det er de eneste to alternativer der er, så kunne jeg forestille mig jeg ville benytte mig at den første.
Tak for svaret; jeg må erkende at mine opdagelsesevner ikke er kommet længere end til MySQL på trods af der findes mange gode alternativer.
Jeg tror jeg vil gå med forslag #1 :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.