1c vegyületet típusok válnak szakértő 1s
Tekintettel a jelenlegi szörnyű állapota a programok, azt mondhatjuk, hogy a programozási határozottan mindig fekete mágia, és még nem tudjuk nevezni technikai fegyelem.
Ennek oka az írás ezt a cikket volt a legfrissebb elemzése ezt a hibát:
Szerver: Msg 8632, Level 17, State 2, 1-es vonal
Belső hiba: Egy kifejezés szolgáltatások határértéket elérték. Kérjük, keresse potenciálisan összetett kifejezéseket a keresett kifejezést, és próbálja egyszerűsítése.
Hogyan kell tárolni a összetett adattípusok az adatbázisban
Első pillantásra, minden nagyon egyszerű. Összetett típus mező az adatbázisban, amelyet két, három vagy több egyedi területeken:
A jó hír azonban az, hogy ezen a rendetlenség dolgokat húr korlátlan hosszúságú és értéktároló nem fog működni 🙂 Ezen a ponton megjegyezzük, hogy még az üres területek az összetett értékek (kivéve a string típusú változó hosszúságú) tárolja a maximális értéket a tárolási méret, nevezetesen:
Ez jelentős felesleges költségeket lemezterület és a memória adatbázis szerver nélkül is figyelembe véve, hogy a tárolt adatok a vonalban 8-kibibaytnym oldalakon.
Következmény 1: összetett típusú vezet jelentős növekedést a méret a mező a rekord.
Nos, a lemez alap tart 30 GiB és 35 GiB - aki ezeket a penny számít, és észre? Közlemény legalább MS SQL Server, ha épít indexek. A maximális hossza egy index 16 mező, vagy 900 bájt. Ezeket a határokat gyakran sérülnek meg a nyilvántartások adatait összetett mezők a méréseket. By the way, az index, és hogy minden rendben lesz, ha index az összetett területen? A legegyszerűbb esetben, például, azt index az összetett területen könyvtár (. Anélkül, hogy további rendelés), több indexek kell építeni minden alap típusa:
Öt indexek. Szerencsére a leggyakoribb eset, amikor egy összetett típusú referencia több területen, és vannak más típusú, csak egy index. De indexek egyetlen területen - ez nem számít. A hiba akkor jelentkezik, amikor az alkatrész területeken több indexek mérések nyilvántartásokban. Végtére is, a platform megpróbálja létrehozni egy indexet az egyes kombinációja bázis típusú (regiszterek információt a fő bejegyzési tábla a nyilvántartások felhalmozódás és számviteli - az eredmény a táblázatokat). Jelenleg 3 „univerzális” dimenziót, és 126 indexek (a nyilvántartásba információ 5 * 5 * 5 kompozit mezők + 1 speciális belső mező). Valószínűleg annak a ténynek köszönhető, hogy a MS SQL Server több mint 254 index nem építhető, a negyedik és az azt követő mezők az index egyszerűen nem vesz részt, de nem vezet hiba.
Következmény 2 kompozit mezők által létrehozott számos indexek. A regisztrációhoz információkat az összetett mérési LOTS indexek.
Ezek az indexek vegye fel lemezterületet, hogy az idő, hogy helyezze / módosítása / törlése bejegyzések, rendszeres karbantartást igényelnek. Valaki azt mondja: „Igen, jól van! Hagyja, hogy, de a mintavételi sebesség!”. Igaz ez? Kereséséhez műveletet az egyik érték - igen. Sok más esetben - nem.
Példa. Tegyük fel, hogy egy összetett mező Spravochnik1 SostavnoePole (tartalmazhat egy számot, vagy egy hivatkozás dokumentum1) és Spravochnik2 ugyanolyan összetett területen SostavnoePole (tartalmazhat egy számot, vagy egy hivatkozás dokumentum1). SostavnoePole indexelt mindkét könyvtárat. Van egy fajta érdeklődés:
Indexek? Elfelejteni. Ha továbbra is írni egy ilyen lekérdezést, akkor azonnal halogatni 120.000 rubelt, és akarata lemondását.
A következő körben a terror kezdődik elérésekor kellékek kellékek. Gyakran lusta programozók írni valami ilyesmit Registrator.Osnovanie.Kontragent vagy Subkonto1.Vladelets.Kod.
Példa. Hagyja, hogy a dokumentumokat az előző példa, van egy mező Base, és lehet, hogy egy összetett (RaskhodnayaNakladnaya és PrihodnayaNakladnaya) és egy területen ügyfél. Nézzük meg, hogyan fog végezni egy vizsgálatot:
És akkor kell elvégezni, mint ez (a szögletes zárójelben a mező adatbázis, a „részek” a kompozit kitölteni):
Példánkban ez rendkívül egyszerű lekérdezés eredményét táblázatban 6 vegyületekre 7, 7 ahol minden asztal nagy esélye, hogy egy teljes scan a fürtözött index (azaz lényegében egy táblázatot scan) használata helyett a megfelelő kódokat, akkor is, ha van ilyen. Ne utasítsa el „Van egy kis bázis, és így jött le!” Teljesítménye a kérelem egyes esetekben csökkentheti a mértékét az asztalok száma. Mit jelent ez a gyakorlatban? A gyakorlatban ez azt jelenti, hogy ebben az esetben is a kérelem primitív lehet 128-szor lassabb, ha a dokumentumok száma, illetve lassítani kétszer duplájára növelésével iratok mennyisége 10%. A tipikus konfigurációban, ahol a vegyület típusa lehet több tíz vagy több száz egyszerű, az ilyen kérelmek szinte mindig vezet jelentős teljesítmény problémák. Egy másik negatív pont szükségtelenné válhatnak, amikor a zár az ilyen kérelmeket az ügylet (például során a dokumentumot) nem elég, hogy a lekérdezés fut tovább és tovább, így is az összes többi felhasználó folyamatosan esik ki a zár timeout.
És ez elég szomorú ez lesz a munkája ezt a kérelmet, ha az összetett típus tartalmazhat nemcsak hivatkozik a feltételek és a kapcsolatok még inkább nehézkes és gyorsan lebomlik.
Tárgyalása nélkül helyességét vagy helytelenségét az eredeti probléma, megpróbáljuk megérteni, hogy ez lehetséges, hogy rögzítse egy ilyen kérés „kis vér” megváltoztatása nélkül az építészet, a megoldás? Nagyon is lehetséges, de azon az áron, ez lesz a méretét és olvashatóságát a lekérdezés:
Ebben a megvalósításban, lett egy kicsit több kapcsolatot, de ezek használata garantáltan a megfelelő indexek. Ezen túlmenően az ütemező MS SQL Server lekérdezések kapnak egy kicsit több szabadságot a választás tervek segítségével a belső kapcsolat - ez szimmetrikus az asztalok, és ebben az esetben jobban tükrözi a lényeget.
Ebben a változatban, általában a kiviteli tervek kevésbé stabilak lehetnek, és nagyban függ a statisztikai adatok. De ebben a megvalósításban kevesebb vegyületek jelenlétében megfelelő indexek (és sikeres összefolyás csillag alatt az ütemező) lehet gyorsabb.
Most láthatjuk, hogy miért egy szerény kifejezése Subkonto1.Vladelets a kérelmet a maradványait számviteli nyilvántartás, és különösen az a része, ahol a kérelmet, felzárkózás pánik bennem?
Következmény 8. kellékek értékek összetett típus akkor több baloldali vegyületek lehetnek elég sokat, és ez ronthatja a teljesítményt a lekérdezést. A kellékek kellékek a értékei kompozit típusú (Pole1.Rekvizit1.Rekvizit2 ahol legalább Pole1 vegyületet) használt nagyon nehézkes és nem hatékony struktúrák.
Nem mindig az összetett típus egy „jó” döntés. Például, ha az érték egy összetett típusú jelenik meg a jelentésben, hogy van egy dilemma:
Következmény 9. Ha kap egy ötletet, összetett típusú lekérdezést, akkor ez vezet a nagy számú vegyület. Ha kap, akkor a kimenet, mint a jelentés, ez vezet a nagy számú kérelmek. Jó hír van.
Az értékek az összetett típusú összetett kifejezések lekérdezések
Szeretnénk megmutatni, hogyan lehet megvalósítani a munka a komponens típusok egyes kifejezések lekérdezés nyelv:
- Összesített funkciók (min, max, szám)
- Segítségével kifejezések SELECT ... AMIKOR ... THE END
Megmutatom példák ilyen ideiglenes tábla: