--- title: "Smart att ha tabell för alla kategorier eller inte?" type: "forum-thread" url: "https://www.webforum.nu/amne/databaser-sql/192044-smart-att-ha-tabell-för-alla-kategorier-eller-inte" topic: "Databaser & SQL" topic_url: "https://www.webforum.nu/amne/databaser-sql" author: "bassebhu" published: "2014-03-14T00:20:31.000Z" updated: "2014-05-01T19:09:10.000Z" replies: 3 views: 2274 page: 1 pages: 1 language: "sv-SE" site: "webForum — webforum.nu" rights: "Upphovsrätten till varje inlägg tillhör dess författare." attribution: "Citera som: webForum, https://www.webforum.nu/amne/databaser-sql/192044-smart-att-ha-tabell-för-alla-kategorier-eller-inte" --- # Smart att ha tabell för alla kategorier eller inte? ## #1 — bassebhu, 2014-03-14T00:20Z Hallå! Jag har just nu 5 olika tabeller med olika kategorier som jag hämtar in med 5 sql-satser. Jag tänker att detta borde kunna göras i en tabell och en enda fråga. Vad tror ni? Det är två tabell-typer för de fem kategorisorterna (3 har den första och 2 den andra) och de ser ut såhär: ID - PID - TITEL - BG_COLOR - FG_COLOR - ORDER resp. ID - PID - TITEL - ABBR_TITEL - ORDER ID är auto_increment PID tänkte jag ska vara NULL om kategorierna ska nås i alla projekt eller en kommaseparerad sträng/serialized array med projekt-id:n om de bara ska nås från vissa projekt (behövs verkligen en extra tabell för detta annars? Jag tänker mig att man hämtar ut alla kategorier jämt ändå) TITEL är kategorinamnet ABBR_TITEL är en förkortning av titeln och ska bara finnas till två av kategorisorterna BG_COLOR och FG_COLOR innehåller 6 tecken långa koder för färger, ex. 0066cc och dessa två fält gäller endast tre av kateorierna ORDER är siffror som talar om i vilken ordning de ska listas Just nu har jag runt 50 kategorier totalt och jag kan tänka mig att det blir runt 50-100 som max, men det beror helt på vad användaren väljer att lägga in. Tänker jag fel när jag försöker att baka ihop olika grejer såhär eller är det smart? Vissa av fälten används bara till vissa av kategorierna som sagt så det blir lite NULL-värden. Å andra sidan känns det lockande att ha ett gemensamt inmatningssystem för allt, en sql-fråga för att hämta klabbet och slippa 70 JOINS i mina frågor. Tack för tips! Permalänk: https://www.webforum.nu/p/192044 ## #2 — gbv, 2014-03-19T06:06Z Det här är ju ett problem med relationsdatabaser, att jobba med träd strukturer. Jag har inte implementerat det själv men gillar lösningen här . Naive trees på slide 49, det kommer en lösning som dom kallar "closure table" som ser ut att verka vettig. Permalänk: https://www.webforum.nu/p/2315742 ## #3 — aasah, 2014-04-25T21:39Z Databaser är optimerade för att kunna göra JOINer blixtsnabbt om du har en vettig struktur på din data, och att inmatningen blir enkel för **dig** är inte tillnärmelsevis lika viktigt som att du har en vettig struktur på din relationsdatabas. Jag skulle dels ha en tabell för alla kategorier, tex: Kategorisort (ID - PID - TITEL - ABBR_TITEL - BG_COLOR - FG_COLOR - ORDER) En del kategorier får då nullvärden på ABBR_TITEL och andra på BG_COLOR - FG_COLOR, men det är OK eftersom dessa inte är nyckelkolumner. Sedan en kopplingstabell mellan Kategorisorten och Projektet: ProjektKategori (ProjID, KategoriID) // En kombination per rad Visst det blir många rader, men går betydligt fortare för databasen att hitta alla projekt som har en viss kategori, eller att utföra JOIN mellan dessa och visa all info om projekt OCH kategorisorter, än om databasen måste göra strängjämförelser i en lagrad lista. Permalänk: https://www.webforum.nu/p/2316052 ## #4 — bassebhu, 2014-05-01T19:09Z Allright, tack! Besegrad igen! Permalänk: https://www.webforum.nu/p/2316108 --- Tråden på webben: https://www.webforum.nu/amne/databaser-sql/192044-smart-att-ha-tabell-för-alla-kategorier-eller-inte