Megint Több-a-Többhöz.. ezúttal ASP.Net
Sziasztok!
Nekem ezekkel a több-a-több kapcsolatokkal meggyűlik a bajom. Most ASP.Net 2.0 felé tervezek db szerkezetet (úgy értve felé hogy a default user,profile,role provider mellé (ASPNETDB.MDF) készítek még táblákat).
Van benne egy érdekes tábla alapból. Az aspnet_UsersInRoles. Két oszolopa van összesen: UserId és RoleId (egyértelmű h több-a-többhöz kapcsolatos tábla). De csak most figyeltem fel, hogy mind a két oszlop PK-nak van beállítva.
Legjobb tudásom szerint ha vmi Pimary key, akkor a táblában, a pk-nak beállított oszlopban egyszer szerepelhet ugyanaz az adat, tehát minden sorban csak különböző lehet. Kíváncsiságból beraktam egy usert több role-ba és egy role-ba több usert. Megnéztem a táblát, és gond nélkül sokszorosodnak mind a két "oldalán" a guid típusú elemek.
Hogy lehet ez?
Segítségül itt egy keys/indexes ablak:
Egy turpisság azért van benne. Hiába PK mindkettő (tehát automatikusan indexelődik és unique is mindkettő), a RoleIdnak még be van állítva egy ilyen:
Minek van benne kétszer h index az oszlop. Hisz ha PK akkor indexelődik!? De a legérdekesebb kérdés mégiscsak hogy hogy tud ugyanolyan elemeket tárolni.
Most akkor én tanultam rosszul valamit (ill. olvastam fél órája 3-4 rossz cikket erről), vagy M$nél valamit nagyon tudnak? :-)
Előre is köszönöm a válaszokat! :-)
■ Nekem ezekkel a több-a-több kapcsolatokkal meggyűlik a bajom. Most ASP.Net 2.0 felé tervezek db szerkezetet (úgy értve felé hogy a default user,profile,role provider mellé (ASPNETDB.MDF) készítek még táblákat).
Van benne egy érdekes tábla alapból. Az aspnet_UsersInRoles. Két oszolopa van összesen: UserId és RoleId (egyértelmű h több-a-többhöz kapcsolatos tábla). De csak most figyeltem fel, hogy mind a két oszlop PK-nak van beállítva.
Legjobb tudásom szerint ha vmi Pimary key, akkor a táblában, a pk-nak beállított oszlopban egyszer szerepelhet ugyanaz az adat, tehát minden sorban csak különböző lehet. Kíváncsiságból beraktam egy usert több role-ba és egy role-ba több usert. Megnéztem a táblát, és gond nélkül sokszorosodnak mind a két "oldalán" a guid típusú elemek.
Hogy lehet ez?
Segítségül itt egy keys/indexes ablak:
Egy turpisság azért van benne. Hiába PK mindkettő (tehát automatikusan indexelődik és unique is mindkettő), a RoleIdnak még be van állítva egy ilyen:
Minek van benne kétszer h index az oszlop. Hisz ha PK akkor indexelődik!? De a legérdekesebb kérdés mégiscsak hogy hogy tud ugyanolyan elemeket tárolni.
Most akkor én tanultam rosszul valamit (ill. olvastam fél órája 3-4 rossz cikket erről), vagy M$nél valamit nagyon tudnak? :-)
Előre is köszönöm a válaszokat! :-)
Összetett kulcs
Ez egy összetett kulcs lesz, ami azt jelenti, hogy a két(vagy több) kulcs mezőnek együtt kell egyedinek lennie.
Vagyis ha megpróbálod kétszer ugyanazt a rekordot beilleszteni (mindkét mező ugyanaz mint korábban), akkor az már nem fog menni...
üdv,
Halee
[szerk]
Illetve most nézem, hogy az ignore duplicate key is no értékre van állítva...
Aha! Megvan
Az teljesen jó amit mondtál. Most terveztem másik DB-t és ott én is megláttam ennek az értelmét. A lényeg hogy a UserId és a RoleId valóban egyszerre nem lehetnek ugyanazok. Mivel ez egy darab PK-nak vehető, nem számít hogy az ignore duplicate key mire van állítva, mivel a PK ösztönéből eredendően nem tud ismétlődni több rekordon keresztül. (Így egy rekord - két oszlopos bejegyzés - sem tud)
A RoleId azért van indexelve hogy az olvasás oda-vissza gyorsan menjen. Tehát a PK automatikusan indexelődik, de arról nem szól a fáma hogy mi van ha először nem a UserId hanem a RoleId szerint akarok lekérdenzi. Akkor az alapból nincs indexelve, lassú.
A másik DB-mben én inkább úgy oldottam meg mint az úriember EBBEN A CIKKBEN.
Tehát balról jobbra olvasva egy PKnak tekinthető, jobbról balra meg mind a kettő UNIQUE INDEXként van beállítva, nyílván ha egyik felől nem tud ismétlődni akkor a két oszlop a másik oldal felől sem. S azt írja ez a leggyorsabb módszer, bár a fentihez képest szerintem csak ízlés kérdése ez a logika.