Char vagy varchar talán blob

előző ◈ a következő

Jellemzői húr adattípusok

Nézzük ismételje meg a leírása ezen adattípusok dokumentáció (Data Definition Guide):
  • CHAR (n) - az n szimbólumok, 1-től 32.767, fix hosszúságú string típusú. Ha a mező tartalma kisebb, mint a megadott méret, ez „igazított” (lehet elérni a) a további terek.
  • VARCHAR (n) - az n szimbólumok, 1-től 32.767, egy változó hosszúságú karakterlánc típusú. Spaces végén a mező tartalmát figyelmen kívül hagyja.

A maximális hossza string típusú függ karakterkészlet. karakterkészletek vannak felsorolva a Data Defintion Guide (A függelék) és Language Reference (Függelék D). Minden egyes sor mutatja a bájtok számát hozott egy karaktert. Ha az egyik karakterkészlet foglal egynél több bájtot, a maximális hossza egy string mező 32767 / Number vo_bayt_na_simvol (azaz UNICODE_FSS - .. 10922 karakter).

A lemezes mindig tele van. Azaz, a követő szóközök nem fontos, hogy a lemezterület szempontból.

Száma záró szóközöket is figyelembe vesszük, hogy csak a varchar. Az érték char „keresi” a terek a hossza bejelentett csak vele készült megbízás vagy adatátvitel a kliens oldalon.

Ezért a tárolás szempontjából a hatékonyság közötti különbség char és varchar gyakorlatilag nincs. És dolgozni kell választani, ami sokkal kényelmesebb. Általában ez egy varchar.

Client komponensek (vagy nem), hogy végre a körülmetélés végére rések CHAR oszlopokat. Attól függően, hogy a hajlandóság a fejlesztő kit rések körülmetélés lehet az alapértelmezett, és szükség lehet a telepítés True vagyon vagy DataSet szinten vagy a szint az adott területen (TStringField). Ezért, ha megkínozták sorvégi szóközöket vonalakat, nézd meg a tulajdonságait az alkatrész.

Meg kell jegyezni, hogy nem BDE vagy dbExpresst nem tudja végrehajtani a körülmetélés záró szóközöket a sorok.

Területek BLOB

Vannak előre definiált altípust (SUB_TYPE) BLOB: 0 - bináris adat 1 - szöveges adatokat. Valójában nincs különbség köztük és altípus csak akkor vonatkozik az alkalmazás (vagy írásakor BLOB szűrők). Egyedi altípusok lehet meghatározni megadásával SUB_TYPE negatív előjellel - .. -1, -2, -10, -200, és így tovább, és ismét csak az fontos alkalmazások üzemi adatokat vagy a szűrő.

BLOB szegmensek mindig írva, hogy a szabad hely, és hogy csak a tényleges térfogat BLOB adatok.
Ha a BLOB mérete nagyobb, mint az oldal mérete, majd hozzon létre egy sor mutató a BLOB oldalt. Nagyon nagy méretben jelenhet BLOB BLOB mutatókat az index oldal.

Ha megváltoztatja a felvételt, ha a folt tartalma nem változott, blobID ugyanaz marad. Tény, hogy az új változat írásos feljegyzések csak azokat a mezőket, amelyek megváltoztatták. Következésképpen, ha a felvétel a módosítás, ha nem befolyásolja BLOB mező folt adatok nem „duplikált”. Ha a folt változik a változat a rekord, mert a lemezen két példányban - a régi és az új. Tekintsük ezt festékfoltok, hogy tárolni nagy mennyiségű adat.

Megjegyzés. Az index mezők Blob lehetetlen.

CHAR vagy BLOB?

Tehát, mi tekinthető minden szempontból a boltban CHAR adatokat, és a VARCHAR BLOB, és most felsorolni iránymutatások a választott típus:
  • Ha a hossz mezőt <255 символов, то
    • jobb kihasználása VARCHAR - tároló varchar 2 byte hosszabb char, de az alkalmazások nem kell írni, vágás záró szóközöket a sorok.
    • régebbi verziói IB segítségével VARCHAR lehet probléma van, amikor a TCP / IP protokollt.
    • Ez nincs értelme, hogy egy BLOB - BLOB végzett mintavétel annak azonosítója, így van egy kicsit hosszabb és valamivel több, mint a költsége programozás.
  • Ha a mező hossza> 255, de < 10000 символов
    • Ezt fel lehet használni, mint egy CHAR vagy VARCHAR és BLOB. Az indexelés mezők ennek hossza lehetetlen, sőt, van esély arra, hogy ha egyszer felvett adatok meghaladják a 10.000 karaktert, és lehet BLOB fér többé. Összpontosít csak a használhatóságát az ilyen adatokat az alkalmazás.
  • Ha a mező hosszának> 5000 karakter, vagy az információ lehet önkényes
    • jobb kihasználása BLOB. Altípus lehet bármilyen információt is tárolhat egy tetszőleges és nem kell aggódnia az adatmennyiség. Az ára adathozzáférés ilyen méretű teljesen ellensúlyozta a különbség a módszerek tárolására és visszakeresésére a CHAR és BLOB mezőket.
  • Egy további tényező a választás lehet egy oldal mérete. Amikor az oldal mérete is 8K tároló sorban válasszuk CHAR vagy VARCHAR, hosszuk is meghaladja 8K (felvétel átléphetik az oldalt úgy, hogy még ha az oldal mérete 1K nyilvánítja 32K sorok hosszú). Jó ötlet az ilyen esetekben, hogy hozzon létre egy táblát, és próbálja meg a sebesség vagy a könnyű olvasás különböző lehetőségek mezők kitöltésével a char, varchar és blob ugyanezeket az adatokat.

adatok átalakítása

A Tűzmadár és zöldharkály, a 3. nyelvjárás vált lehetővé a betét (frissíteni?) A csomag tartalma a blob, hogy kérje a szokásos vonalat. A többi szerverek ilyen intézkedések fogják kiadni egy szabványos üzenetet, hogy lehetetlen az adatok átalakítása.

Azonban már régóta egy folt UDF átviteli vonal és vissza (FreeUDFLib és mások).

potenciális problémák

indexelés

  • Karakterlánc függetlenül a mező típusát egy korlátozása a hossza az index - 84 bájt megadásakor összeveti és 252 bájt - anélkül LEVÁLOGAT.
  • BLOB-mezők nem indexelt.

Megjegyzés. Írhat saját funkció, hasonlóan a felső és elkerülni ezt a problémát.

az adatok lekérése

  • Amikor egybetoldjuk húr mezőket a lekérdezés kell tekinteni, hogy a KAR-mező „habosított” a megadott hosszúságú terek, VARCHAR - nincs. Például, ha a kérelem „szerelvény”, a vezetéknév, keresztnév és apai

válassza last_name || first_name || middle_name az ügyfelek

Az eredmény körülbelül a következő: „Ivanov Ivan Ivanovich”. És ha ez VARCHAR mező, akkor ugyanezt a kérést ad az eredményt „IvanovIvanIvanovich”.

Hogy oldja meg ezt a problémát, akkor az UDF CHAR (típus RTrim) és a VARCHAR - helyezze extra terek (|| „” ||).

  • A többnyelvű adatbázis BLOB nem lehet átalakítható az egyik kódolás egy másik. Például, ha a szerver támogatja a titkosítást és WIN1251 KOI8R, és létrehozott adatbázisban WIN1251, lehet csatlakoztatni (például közvetlen hozzáférést alkatrészek) mutató LC_CTYPE = KIO8R a kapcsolat paramétereit. Ebben az esetben, az információ átkódolhatóak származó win1251 a koi8r és fordítva minden húr adattípusok kivéve BLOB. akkor is, ha a minta meg kell írni a saját UDF adatkonvertálásra folt.

Behelyezése és módosítási adatok

  • BLOB mezőket nem lehet továbbítani, mint a lekérdezési paramétert vagy egy tárolt eljárás a BDE 2,5x és 3.x (ilyen lehetőség megjelent csak a BDE 4,0 és Y komponens Delphi 3,0). Ez ahhoz vezet, hogy szükség van az adatátvitel és TQuery BLOB-területen keresztül TBlobStream. A szerver önmagában nincs probléma megszerzése vagy továbbítása blob lekérdezési paraméter vagy paraméterek eljárásokat.

Készítsen hordozható adatbázisban

  • ANSI SQL szabvány kifejezetten definiálja típusú mezőkkel, de természetesen a végrehajtás az ilyen típusú, a módszer tárolására és feldolgozására a gyártó határozza meg az egyedi SQL-Server. Annak érdekében, hogy legalább néhány toleranciát lehetséges kell használni típusú kompatibilis, figyelmen kívül hagyva a használatának előnyei az adattípusok (például CHAR a InterBase). Be kell, hogy a dokumentációt, vagy segítséget fájlok BDE (BDE32.HLP), annak érdekében, hogy meghatározzák a kompatibilitást a különböző típusú kiválasztott SQL-szerver.
előző ◈ a következő