Keresés

Új hozzászólás Aktív témák

  • fatal`

    titán

    válasz martonx #17316 üzenetére

    Szerintem a lekérdezés módjától (vagy módjaitól) és gyakoriságától függ, hogy hogyan érdemes indexelni. Ha ugyarra a 3 oszlopra szűrsz mindig, akkor kompozit, mert egy selecten belül, egy táblán csak egy indexet fog használni.

    Nyílván a saját use caseben ő tudja kimérni (esetleg query plannerrel).

    Mondjuk én nem nagyon értem, hogy miért kell az indexeket is EF-fel generálni/generáltatni. Lehet írni hozzá custom migrációt is és akkor létrehozod kézzel.

  • coco2

    őstag

    válasz martonx #17316 üzenetére

    Az a tábla jelenleg 3 másik (a létszámuk később bővülni fog) tábla 1-1 sorához ad többlet információt azon a 3 dimenzión együttesen, és annak okán abban a táblában arra a 3 másik táblára foreign key van (a primary key / ID van bejegyezve). A szitu a sima indexekkel annyi, hogy azokat az EF automatán gyártotta, mert azt mondja, szerinte jók lesznek még valamire. Leszámítva a nagyon barkácsolást, fogalmam sincs, hogyan mondjam meg a migrations-nek, hogy ugyan ne gyártsa már le azokat az indexeket. Szóval ráhagytam. Ami a gyakorlatban tényleg jó lesz valamire, az a kompozit index, mert amikor abban a táblában keresni akarok, mind a 3 értéket tudni fogom. Apropó az az index igazából kompozit key, de nincs annotation support (én nem találtam) kompozit key-t felvenni a primary key mellé, míg index-re van annotation support - szóval index-ként lett kategorizálva. Hát, egy kicsit még szoknom kell a migrations rigolyáit. Lenne egy jó öreg lamp + phpmyadmin-om, nem lennének vele ilyen gondjaim, de most rám olvasták, hogy ezt kell szeretnem. Ennyi az összes nagy titok, nincs itt semmi misztérium, és végleg nem szakmai precizitáshoz van bármi köze a történetnek.

    កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Új hozzászólás Aktív témák