Hver record i tblData tilhører en og kun en Hovedmenu, en og kun en Undermenu1 og ingen eller en Undermenu2.
Hver Undermenu1 tilhører en og kun en Hovedmenu, hvor Undermenu2 tilhører en og kun en Undermenu1 og også en og kun en hovemenu.
Mit mål er at danne et view der medtager alle records i tblData sammen med de relevante informationer fra hver af det tre andre tabeller. Dvs. at der til hver record i viewet er tilknyttet en record fra tblData der er sat sammen med de relevavnte felter for Hovedmenu.titel, Undermenu1.titel og Undermenu2.titel (hvor sidstnævnte godt kan være NULL).
Forholdet mellem Hovedmenu og Undermenu1 var ikke det store problem: Jeg lavede først en fælles tabel af foreignkeys med pk for hver af de to tabeller tblHovedmenu, tblUndermenu1. Således var forholdet mellem alle Undermenu1'er og Hovedmenu etableret (inkl. diagram). Derefter lavede jeg en associationstabel mellem tblData og den nye nyoprettede tabel af foreignkeys fra de to andre. Denne række af tabbeller anvendte jeg så i et view, hvor jeg så til hver record i tblData har de associerede informationer om hovedmenu og submenu.
Men nu ophører min kreativitet også. Hvordan får jeg koblet den sidste information om Undermenu2 på systemet, således at når jeg indtaster et nyt recordset i tblData som tilhører en punkt i tblUndermenu2 også kan få den inkluderet i mit endelige view sammen med information om denne records tilhørsforhold til alle niveauer.
Er der nogen der kan hjælpe mig på vej i denne struktur?
I dette særtema om aspekter af AI ser vi på skiftet fra sprogmodeller til AI-agenter, og hvordan virksomheder kan navigere i spændet mellem teknologisk hastighed og behovet for menneskelig kontrol.
Ja, ja. Jeg skulle lige have udtænkt den anden model først og så skulle jeg på ferie... Modellen blev at samle al information om menuerne/strukturen i en tabel (dvs. både hovedmenu og submenuer) og med en 5-cifret kode afgøre hvor i strukturen den enkelte side hører til. Fx 30579, som skal læses som 3-05-7-9, eller hovedmenu 3, submenu 05, sub-submenu 7 og sub-sub-submenu 9 (sidstnævte forekommer kun sjældent). Tallet er ikke PK i tabellen, så der er et 'løbenummer' til hver menu også, som indgår som FK i tabellen med side-informationerne. På den måde har jeg koblet al data sammen med en komplet nøgle til hvor den enkelte side hører hjemme i strukturen.
En anden fordel ved denne model er at antallet af kald til databasen mindskes og antallet af JOINS minimeres også, så den samlede tid siden skal bruge på at snakke med databasen skulle alt andet lige være minimeret.
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.