Redgate Hub (Magyar)

Az ideiglenes táblák éppen ilyenek. Leggyakrabban arra szolgálnak, hogy munkaterületet biztosítsanak a közbenső eredményekhez, amikor az adatokat egy kötegben vagy eljárásban dolgozzák fel. Ugyancsak használják táblák átadására egy táblaértékű függvényből, táblázatos adatok továbbítására a tárolt eljárások között, vagy újabban táblaértékű paraméterek formájában, egész írásvédett táblák küldésére az alkalmazásokból az SQL Server rutinokra , vagy adja át csak olvasható ideiglenes táblákat paraméterként. Miután befejezték használatukat, automatikusan eldobják őket.

Mielőtt túlságosan elmélyednénk a technológiában, azt tanácsolom, hogy a táblázatváltozókat használja, ahol csak lehetséges. Könnyűek, és az SQL Server elvégzi a munkát. Hajlamosak kevesebb problémát okozni egy szorgalmas OLTP rendszer számára is. Esetenként előfordulhat, hogy finomhangolnia kell őket, hogy jó teljesítményt nyújtson belőlük a csatlakozások során, de ezt egy pillanat múlva elmagyarázom. Ha azonban összetettebb ideiglenes adatok feldolgozását végzi, vagy valószínűleg többet használ, mint ésszerűen kicsi mennyiségű adat, akkor a helyi ideiglenes táblák valószínűleg jobb választást jelentenek.

Táblázatváltozók

A táblázatváltozókat azon rutin vagy köteg körében használják, amelyen belül vannak definiáltak, és eredetileg azért készültek, hogy lehetővé tegyék a táblázat által értékelt funkciókat. Ezek azonban sok olyan felhasználásra alkalmasak, amelyekre a hagyományos ideiglenes asztal került. A hatókör-szabályozásban más változókhoz hasonlóan viselkednek. Ha az alkalmazási körön kívül esnek, azokat ártalmatlanítják. Ezekkel sokkal könnyebb dolgozni és meglehetősen biztonságosak, és kevesebb újrafordítást is kiváltanak azokban a rutinokban, ahol használják őket, mintha ideiglenes táblákat használna. A táblázatváltozók kevesebb zárolási erőforrást igényelnek, mivel „magántulajdonban vannak” az őket létrehozó folyamathoz. A tranzakciók visszagörgetése nem érinti őket, mivel a táblaváltozók korlátozott hatókörrel rendelkeznek, és nem részei a tartós adatbázisnak, így hasznosak olyan adatok létrehozásához vagy tárolásához, amelyeknek túl kell maradniuk a visszagörgetéseknél, például a naplóbejegyzéseknél. A táblázatos változók hátránya, hogy gyakran eldobják őket, mielőtt megvizsgálhatnák a tartalmuk hibakeresését, vagy különböző SQL-kifejezések interaktív kipróbálására használhatnák őket.

Ha az alkalmazás konzervatív, és az adatkötetei világosak Soha nem akarok mást. Azonban eltalálhatja a problémákat. Az egyik nehézség az, hogy a tábla változókra csak a helyi hatókörükben lehet hivatkozni, ezért nem lehet őket dinamikus SQL használatával feldolgozni, mint egy ideiglenes tábla vagy tábla értékű paraméter esetén. Ez azért van, mert nem hivatkozhat egy külsőleg definiált táblaváltozóra a dinamikus SQL-ben, amelyet az EXEC utasítással vagy az sp_ExecuteSQL tárolt eljárással hajt végre, mert a dinamikus SQL a hatókörön kívül kerül végrehajtásra a táblázat változójának. Természetesen létrehozhatja, majd felhasználhatja a dinamikus SQL-ben lévő tábla változót, mert a tábla változó hatókörbe tartozik. A dinamikus SQL futtatása után azonban nem lesz táblázatváltozó.

Néhány rendellenességről is tudatában kell lennie. Például a kezdeti DECLARE utasítás után nem módosíthatja a táblázat definícióját. Az SQL Server 2000-ben egy tábla változó nem lehet egy SELECT INTO utasítás vagy INSERT EXEC (most javítva) célja; Nem hívhatja meg a felhasználó által definiált függvényeket az ELLENŐRZÉSI korlátozásokból, az Alapértelmezett értékekből és a táblázat változójának kiszámított oszlopaiból. Az ELLENŐRZÉSI korlátozásokon túl csak az elsődleges kulcs, az egyedi kulcs és az NULL / NOT NULL korlátozások vannak

A legbonyolultabb problémák azonban a táblák méretének növekedésével járnak, mert az SQL Server 2016 előtt , nem nyilatkozhatott kifejezetten egy indexről, és az UNIQUE és a PRIMARY KEY korlátozásokat érvényesítő indexeknél nem voltak fenntartva az elosztási indexek. Most létrehozhat bizonyos indextípusokat sorban a tábla meghatározásával, de az elosztási statisztikák továbbra sem maradnak rajtuk. A Lekérdezés-optimalizáló feltételezi, hogy csak egy sor van a táblázatban. Nem generálhat párhuzamos lekérdezési terveket egy SQL kifejezéshez, amely módosítja a táblázat tartalmát. Az indexkorlátozás részleges megkerüléséhez korlátozásokkal teheti meg ugyanezt. A legfontosabb az elsődleges kulcs korlátozása, amely lehetővé teszi fürtözött index kiszabását, de az egyedi korlátozások hasznosak a teljesítmény szempontjából. A Lekérdezés-optimalizáló örömmel használja őket, ha vannak.

A táblázatváltozók legnagyobb problémája, hogy a statisztikákat nem tartják fenn az oszlopokon. Ez azt jelenti, hogy a lekérdezés-optimalizálónak tippelnie kell az adatok méretét és eloszlását illetően, és ha rosszul téved, akkor gyenge teljesítményt fog tapasztalni a csatlakozásoknál: ha ez megtörténik, keveset tehet másért mint visszatérni a klasszikus helyi ideiglenes táblák használatához. Az SQL Server 2019-től kezdődően a Microsoft bevezette a Table Variable Deferred Compilation nevű új funkciót, amely megoldja ezt a problémát. További információkért olvassa el ezt a cikket Greg Larsentől.

Ha nem az SQL Server 2019-et használja, akkor megpróbálhatja az OPTION (RECOMPILE) hozzáadását ahhoz az utasításhoz, amely magában foglalja a táblázatváltozó összekapcsolását más táblákkal. .Ezáltal az SQL Server képes lesz felismerni a sorok számát az újrafordításkor, mert a sorok már be vannak töltve. Ez nem oldja meg teljesen a problémát, mivel az optimalizálónak még mindig nincsenek terjesztési statisztikái, és általában rossz terveket tud előállítani, ha az elosztás torz. Ebben a bemutatóban a csatlakozás időben háromnegyedével csökkent, egyszerűen az OPTION (RECOMPILE) hozzáadásával.

Most, ha egyedivé tudja tenni a táblázatokba kerülőt, akkor ezekre használhatja az elsődleges kulcs korlátozását táblázatok. Ez lehetővé tette az optimalizáló számára, hogy fürtözött indexkeresést használjon a táblázat szkennelése helyett, és a végrehajtás ideje túl gyors volt a méréshez. Vannak, akik elég bátran adnak tanácsot a táblázat sorainak számát illetően, én pedig láttam, hogy 100 vagy 1000 ajánlott maximum; de láttam, hogy sokkal nagyobb táblaváltozók tökéletesen kielégítően teljesítenek az idő múlásával, és sokkal kisebbek adnak gondot. Kisebb táblákban azonban a probléma kevésbé észlelhető!

Táblázatértékű paraméterek

A Táblázatértékelt paraméter (TVP) egy speciális típusú táblaváltozó, amely kiterjeszti használatát. Amikor a táblázatváltozókat paraméterként adják át, a táblát a TempDB rendszer adatbázisában táblázatváltozóként materializálják, és hivatkozásként továbbítják, a TempDB táblázatának mutatójaként.

A táblázat értékű paramétereket azóta használják SQL Server 2008 több adatsor elküldéséhez egy Transact-SQL rutinhoz vagy egy köteghez a sp_ExecuteSQL útján. Különleges értékük a programozó számára, hogy a TSQL kódban felhasználhatók, mint ugyanúgy, mint az ügyfélalkalmazásban, így alkalmasak arra, hogy kliens táblákat küldjenek a szerverre. A TSQL-ből deklarálhat táblázatértékű változókat, beilleszthet adatokat beléjük, és ezeket a változókat táblázatértékű paraméterként továbbíthatja a tárolt eljárásoknak és függvényeknek. Általánosabb hasznosságukat korlátozza az a tény, hogy csak írásvédettként továbbítják őket. Nem tehet UPDATE, DELETE vagy INSERT utasításokat egy táblázatban értékelt paraméter a rutin törzsében.

Létre kell hoznia egy felhasználó által definiált táblatípust, és meg kell határoznia egy tábla struktúrát a használatukhoz. Itt van egy egyszerű példa a TSQL-ben való használatukra

A táblázatváltozókhoz hasonlóan a táblaértékű paraméter is megszűnik létezni, ha kívül esik a hatókörön, de a típusdefiníció mindaddig fennmarad, amíg azt kifejezetten eldobják.A táblázatváltozókhoz hasonlóan ők sem szereznek zárakat, amikor az adatokat egy ügyfél tölti ki, és a statisztikákat nem a táblázat értékű paraméterek oszlopai tartják fenn. Nem használhat táblázatértékű paramétert SELECT INTO vagy INSERT EXEC utasítás célpontjaként. Amint az várható volt, egy táblázat értékű paraméter szerepelhet a SELECT INTO FROM záradékban vagy a INSERT EXEC karakterlánc vagy tárolt eljárás.

A TVP megoldja azt a gyakori problémát, hogy egy helyi változót akar átadni dinamikus SQL-nek, amelyet aztán egy sp_ExecuteSQL. A Microsoft ezt kevéssé dokumentálja, ezért bemutatok egy kidolgozott példát a kezdéshez.

Mielőtt továbblépnénk a hagyományosabb ideiglenes táblák és használatuk ismertetésére, be kell mélyednünk a az a hely, ahol ideiglenes asztalokat tartanak. TempDB.

TempDB

Ideiglenes táblák és táblaváltozók a TempDB adatbázisban jönnek létre, ami valójában csak egy újabb adatbázis, egyszerű helyreállítással: A TempDB használatával csak elegendő “minimális” naplózást végeznek a visszagörgetés és más ACID finomságok A TempDB különlegessége, hogy az objektumok, például a táblák, az indításkor törlődnek. Mivel a TempDB mindig az egyszerű helyreállítási modellt használja, az elkészült tranzakció törlődik a következő TempDB ellenőrzőpont naplójából, és csak az élő tranzakciókat őrzi meg. Ez mind azt jelenti, hogy az ideiglenes táblák minden más alaptáblához hasonlóan viselkednek, mivel naplózzák és tárolják őket. A gyakorlatban az ideiglenes táblák valószínűleg tárolva maradnak a memóriában, de csak akkor, ha gyakran használják őket: ugyanazok, mint egy alaptáblánál. A TempDB működteti az ideiglenes objektumok újrafelhasználásának nevezett rendszert, amely gyorsítótárba helyezi az ideiglenes objektumok egy részét a tervvel, ha elegendő memória áll rendelkezésre. Ez annak a jelmondatnak tudható be, hogy az ideiglenes objektumok csak a memóriában léteznek. Az igazság, mint mindig, ez „attól függ…”.

Sok más dolog megy végbe a TempDB-ben: Az adatbázis-motor felhasználhatja a munkaasztalok elhelyezésére a DBCC-ellenőrzésekhez, indexek, kurzorok létrehozásához vagy újjáépítéséhez, például. A „hash”, „sorts” és „spool” leírású lekérdezések köztes táblázatai például a TempDB-ben valósulnak meg, az SQL-utasítások végrehajtásakor számos „fizikai” művelethez szükséges táblákkal együtt. Pillanatkép-elkülönítés, több aktív eredményhalmaz (MARS), triggerek és online-index-build verzióverzió-tárolóként is használható.

Mivel az ideiglenes táblákat ugyanúgy tárolják, mint az alaptáblákat, van egy vagy kettő olyan dolgokra, amelyekre óvakodnod kell. Például CREATE TABLE engedéllyel kell rendelkeznie a TempDB-ben a normál tábla létrehozásához. A gond megtakarítása érdekében ezt alapértelmezés szerint a DBO (db tulajdonos) szerepkörhöz rendeli, de előfordulhat, hogy kifejezetten meg kell tennie azoknál a felhasználóknál, akikhez nincs hozzárendelve a DBO szerepkör. Minden felhasználónak van engedélye helyi vagy globális ideiglenes táblák létrehozására a TempDB-ben, mert ezt a GUEST felhasználói biztonsági környezeten keresztül rendelték hozzá.

A klasszikus ideiglenes tábla bejön két íz, a Globális vagy megosztható, ideiglenes tábla, előtagja: “##”, és a helyi ideiglenes tábla, amelynek neve előtagja: “#”. A helyi ideiglenes táblák kevésbé hasonlítanak a normál táblázatokhoz, mint a Globális ideiglenes táblák: Ön nem hozhat létre nézeteket rajtuk, és nem társíthat kiváltó okokat hozzájuk. Kicsit bonyolult kidolgozni, hogy melyik folyamat, munkamenet vagy eljárás hozta létre őket. Ebben később adunk egy kis segítséget. A legfontosabb, hogy biztonságosabbak, mint egy globális ideiglenes tábla, mivel csak a tulajdonosa tudja látni.

A helyi ideiglenes tábla (és a helyi ideiglenesen tárolt eljárás) másik furcsasága, hogy más néven van a metaadatokban annak, amelyet a rutinjában vagy a tételben megad Ha ugyanazt a rutint egyszerre több folyamat hajtja végre, az adatbázis-motornak képesnek kell lennie megkülönböztetni a különböző folyamatok által létrehozott, azonos nevű helyi ideiglenes táblákat. Ezt úgy teszi meg, hogy numerikus karakterláncot ad az egyes helyi ideiglenes táblák nevéhez, amelyeket aláhúzás karakterekkel tölt be. Annak ellenére, hogy megadja a rövid nevet, például #MyTempTable, a TempDB-ben valójában az CREATE TABLE utasításban megadott táblanév alkotja és az utótagot. Ezen utótag miatt a helyi ideiglenes táblák nevének legfeljebb 116 karakterből kell állnia.

Ha érdekel, hogy mi folyik itt, a TempDB-ben lévő táblákat ugyanúgy megtekintheti, mint bármely más táblát. asztal. A sp_help work ideiglenes táblákon is csak akkor használható, ha a TempDB-ből hívja meg őket.

vagy megtalálja őket a TempDB rendszernézeteiben adatbázisok elcsúszása nélkül.

Vagy az információs séma

Még jobb, ha megtudhatja, hogy milyen folyamat és felhasználó ragaszkodik a TempDB hatalmas ideiglenes tábláihoz, és nem hajlandó feladni a helyet.

Csak ideiglenes táblákban használhatja a felhasználó által definiált adattípusokat, ha az adattípusok nem léteznek a TempDB-ben; vagyis kivéve, ha az adattípusokat kifejezetten létrehozták.

Felhasználói táblázatok a TempDB-ben

Normál használat esetén ideiglenes táblákat vagy táblaváltozókat hoz létre anélkül, hogy túl mélyen átgondolná őket. Érdekes azonban, hogy a TempDB bármilyen homokozó tevékenységre alkalmas. Létrehozhat rendes alaptáblákat, nézeteket vagy bármi mást. Létrehozhat sémákat, tárolt eljárásokat és így tovább. Nem valószínű, hogy ezt meg akarja tenni, de ez biztosan lehetséges, mivel a TempDB csak egy másik adatbázis. Éppen most kellett újraindítanom az SQL Server fejlesztésemet, miután ezt bizonyítottam magamnak az AdventureWorks telepítésével. Ez azt jelenti, hogy a TempDB-ben lehet létrehozni egy alaptáblát, egyfajta .. vagy … ideiglenes állandó táblát. A globális ideiglenes asztallal ellentétben a saját háztartását meg kell tennie rajta: egyedül van. Ugyanez vonatkozik a rutinokra is. Ennek az az előnye, hogy bármilyen feldolgozás, amelyet végez, a TempDB egyszerű helyreállítását használja, így ha nem sikerül feltörölnie, az SQL Server a következő indításkor anyaként működik: bár ez nagyon hosszú ideig tarthat. A következő szakasz az, hogy úgynevezett „kitartó ideiglenes” asztal legyen. Ebben a táblázatban maga az adat is ingatag, amikor a szerver újraindul, de maga a tábla továbbra is fennáll. Valószínűleg a perzisztens ideiglenes tábla létrehozásának leggyakoribb módja egy globális ideiglenes tábla létrehozása indításkor. Ez automatikusan megtehető, amikor az összes adatbázis helyreáll, és a “Helyreállítás befejeződött” üzenet naplózásra kerül. Annak ellenére, hogy ez egy “globális ideiglenes”, még akkor sem törli, ha az összes azt használó kapcsolat eltűnt, mert az azt futtató folyamat Soha nem tűnik el. Vitathatatlan, hogy jobb, ha ilyen típusú táblázatot készít az azt használó adatbázisban, bár ha teljes helyreállítást használ, akkor az ideiglenes munka a naplóban marad. Természetesen egyszerűen létrehozhat egy közönséges tábla a TempDB-ben. Ezeket a “tartós” táblákat indításkor létrehozhatja úgy, hogy meghatároz egy tárolt eljárást a masterben, amely létrehozza a globális ideiglenes táblázatot.

Miért érdemes használni ezt a fajta hibrid táblát? Van például egy szám technikák a táblák áthelyezésére az eljárások között „perzisztens” táblákon keresztül, többfolyamat-biztonságos módon, az adatok feldolgozásának sorozatához. Ezeket egy folyamatkulcsos táblákra utaljuk (lásd: „Hogyan lehet adatokat megosztani a tárolt eljárások között”) : Process-Keyed táblázat: Erland Sommarskog ). Kezdetben minden tapasztalt DBA szemöldökét felvonják, de hatékony és biztonságos megoldást jelentenek egy évelő problémára, ha megfelelően elkészítik őket.

Az ideiglenes asztalok mellett számos asztaltípus is létezik. amelyek nem közvetlenül az alaptáblákból származnak, például a „hamis” táblákból és a származtatott táblázatokból: ezek némelyike annyira röpke, hogy leginkább átmenetinek, és inkább ideiglenesnek gondolják őket. A CTE átmeneti táblázatokat használ, amelyek „inline” vagy „származtatottak” és nem valósulnak meg. A BOL „ideiglenesen megnevezett eredményhalmazként” emlegeti őket. Csak a kifejezés keretein belül léteznek. A CTE-ben előnyük van a származtatott táblázatokkal szemben, mivel többször is elérhetik őket.

Helyi ideiglenes tábla

Helyi ideiglenes táblával (# -vel kezdődő nevek), ami a motorháztető alatt zajlik, meglepően hasonlít a táblázatváltozókra. A Táblázat Változókhoz hasonlóan a Helyi Ideiglenes táblák is privátak a létrehozó folyamathoz. Ezért nem használhatók nézetekben, és nem lehet hozzájuk társítani az eseményindítókat.

Könnyebben kezelhetők, mint a táblázatos változók, ha a SELECT INTO -t szeretné létrehozni, de kissé óvatos vagyok a SELECT INTO egy olyan rendszerben, amely valószínűleg módosítást igényel, sokkal inkább szeretném az ideiglenes táblákat kifejezetten létrehozni, az összes szükséges korlátozással együtt.

Nem lehet könnyen megmondani, hogy melyik munkamenet vagy eljárás jött létre ezeket a táblázatokat. Ennek az az oka, hogy ha ugyanazt a tárolt eljárást több folyamat egyszerre hajtja végre, az adatbázis-motornak képesnek kell lennie a különböző folyamatok által létrehozott ugyanazok a táblák megkülönböztetésére. Az Adatbázis-motor ezt úgy teszi meg, hogy belsőleg hozzáad egy balra kitöltött numerikus utótagot az egyes helyi ideiglenes táblák nevéhez. A TempDB sys.objects nézetében tárolt ideiglenes tábla teljes nevét az CREATE TABLE utasításban megadott táblanév és a rendszer által generált numerikus utótag alkotja. Az utótag engedélyezéséhez a helyi ideiglenes névhez megadott táblanévnek kevesebbnek kell lennie, mint 116 karakter.

Helyi ideiglenes táblákkal takarít meg; automatikusan kiesnek, ha kilépnek a hatókörből, hacsak nem kifejezetten a DROP TABLE használatával dobják ki őket. Hatáskörük nagyobb, mint egy táblázatos változó, így nincsenek problémáik kötegekben vagy dinamikus SQL-ben történő hivatkozással. A helyi ideiglenes táblák automatikusan eldobódnak az aktuális munkamenet vagy eljárás végén. A létrehozó eljárás végén való eldobása fejfájást okozhat: egy tárolt eljárásban vagy munkamenetben létrehozott helyi ideiglenes tábla leesik, amikor befejeződik, így nem lehet hivatkozni arra a folyamatra, amely a tárolt eljárást létrehozta az asztalt. Hivatkozni lehet azonban a táblát létrehozó tárolt eljárás által végrehajtott beágyazott tárolt eljárásokra. Ha a beágyazott eljárás hivatkozik egy ideiglenes táblára, és abban az időben két azonos nevű ideiglenes tábla létezik, melyik tábla ellen oldódott a lekérdezés?

Érdekességként helyi ideiglenes tárolt eljárásokat is létrehozhat ugyanaz a hatókör és élettartam, mint egy helyi ideiglenes tábla. Nem teheti ugyanezt más rutinok esetében.

Globális ideiglenes táblázatok.

A helyi ideiglenes táblázatokhoz hasonlóan a globális ideiglenes táblák (# -vel kezdődnek) automatikusan eldobódnak, amikor a táblázatot létrehozó munkamenet véget ér: nem privátok az azt létrehozó folyamathoz, addig is fenn kell maradniuk, amíg az utolsó Transact-SQL utasítás, amely aktívan hivatkozott a táblára abban az időben, amikor a létrehozó munkamenet befejeződött, befejezi a végrehajtást, és a zárakat eldobják. Bárki, akinek hozzáférése van a TempDB-hez ezen globális ideiglenes táblák fennállása idején, közvetlenül lekérdezheti, módosíthatja vagy eldobhatja ezeket az ideiglenes objektumokat.

Szabályokat, alapértelmezéseket és indexeket társíthat ideiglenes táblákhoz, de nézeteket nem hozhat létre. ideiglenes táblákon, vagy társítson hozzájuk triggereket. Csak akkor használhat felhasználó által definiált adattípust ideiglenes tábla létrehozásakor, ha az adattípus létezik a TempDB-ben.

A tárolt eljárások hivatkozhatnak az aktuális munkamenet során létrehozott ideiglenes táblákra. Tárolt eljáráson belül nem hozhat létre ideiglenes táblázatot, dobhatja le, majd hozhat létre új, azonos nevű ideiglenes táblázatot.

Bár ez működik …

… ez nem t

Helyi ideiglenes táblák használatával akaratlanul is kényszerítheti az újrafordítást a tárolt eljárás minden használatára. Ez nem jó, mert a tárolt eljárás valószínűleg nem fog jól teljesíteni. Az újrafordítás elkerülése érdekében kerüljön hivatkozás egy hívó vagy meghívott tárolt eljárásban létrehozott ideiglenes táblára: Ha ezt nem tudja megtenni, akkor tegye a hivatkozást egy karakterláncba, amelyet azután a EXECUTE utasítás vagy sp_ExecuteSQL tárolt eljárás. Győződjön meg arról is, hogy az ideiglenes tábla létrehozva van-e a tárolt eljárásban vagy indítóban, mielőtt hivatkoznának rá, és elvetnék ezeket a hivatkozásokat.Ne hozzon létre ideiglenes táblázatot az áramlási vezérlő utasításban, például IF... ELSE vagy WHILE.

Engedélyezheti a globális ideiglenes tárolt eljárások létrehozását, de még nem találtam azok használatát. A globális ideiglenes funkciók nem engedélyezettek.

Következtetések

Bármely megosztott játszótéren legyen nagyon óvatos, hogy hogyan lendítse meg az ütőt. Ezt olvasva rájött, hogy sok tevékenység folyik a TempDB-ben, és pusztítást okozhat az egész SQL Server számára hosszú ideig futó folyamatok használatával, amelyek ideiglenes táblákat töltenek fel, bármilyen típusúak is, felesleges mennyiségű adat. Valójában ebben a cikkben nyomokat adtam Önnek arról, hogyan lehet valóban, valóban felborítani a DBA-t az értékes megosztott erőforrás, a TempDB nem megfelelő használatával. (Az S2005 előtti régi időkben a SELECT INTO és egy hatalmas asztal használata nagyszerű V-fegyver volt (Vergeltungswaffe).

Mindig ódzkodom a általános tanácsok, de mindig jobban szeretem, ha az adatbázisaim a táblázatváltozókat és a TVP-ket használják, ahol csak lehetséges. Kevesebb erőforrást igényelnek, és kevésbé valószínű, hogy ragaszkodik hozzájuk, ha végzett velük. , oszlop- és táblázatellenőrzésekkel és korlátozásokkal. Találhat olyan eseteket, amikor elfogy a gőz, különösen akkor, ha az asztalméretek nagyobbak lesznek. Ilyen esetekben, vagy ha korlátozott hatókörük miatt nem célszerű táblázatváltozókat használni, akkor Helyi ideiglenes asztalokat fogok használni. Sok ajkakra és fejcsóválásra van szükség, mire egyetértek egy globális ideiglenes asztallal vagy állandó ideiglenes asztallal. Néhány érvényes és teljesen ésszerű felhasználási lehetőségük van, de a programozó elvégzi a szükséges háztartást