Char sau varchar poate pată de cerneală

anterior ◈ următoarea

Caracteristici ale tipurilor de date șir de caractere

Să repetăm ​​descrierea acestor tipuri de date de documentație (Ghid de date) Definiție:
  • CHAR (n) - n simboluri, de la 1 la 32.767, lungime fixă ​​de tip șir. În cazul în care conținutul câmpului este mai mică decât dimensiunea specificată, este „aliniate“ () Realizeaza spatiile suplimentare.
  • VARCHAR (n) - n simboluri, de la 1 la 32.767, un tip de șir de lungime variabilă. Spații la sfârșitul conținutului câmpului sunt ignorate.







Lungimea maximă a tipurilor string depinde de setul de caractere. seturi de caractere sunt enumerate în Ghidul defintion de date (Anexa A) și limbă de referință (Anexa D). Pentru fiecare set arată numărul de octeți luate de un singur caracter. În cazul în care un set de caractere ocupă mai mult de un octet, lungimea maximă a unui câmp șir este vo_bayt_na_simvol 32767 / Numărul (de exemplu, pentru UNICODE_FSS - .. 10922 de caractere).

Pe înregistrarea discului este întotdeauna ambalat. Aceasta este, spațiile rămase în urmă sunt lipsite de importanță pentru perspectiva spațiu pe disc.

Numărul de spații suplimentare la final este luată în considerare numai la varchar. Valoarea char „caută“ cu spații la lungimea declarată numai atunci când el face prin cesiune sau transmiterea de date pe partea de client.

Prin urmare, în ceea ce privește diferența de eficiență de stocare între char si varchar practic nici unul. Și pentru a lucra aveți nevoie pentru a alege ceea ce este mai convenabil. De obicei, acesta este un varchar.

Componentele client pot (sau nu pot) pentru a efectua tăierea împrejur pentru coloane libere finale CHAR. În funcție de înclinarea dezvoltator lacune kit circumciziei poate fi implicit, și poate necesita instalarea la True orice proprietate sau setul de date de nivel sau la nivelul domeniului specific (TStringField). Prin urmare, dacă ați torturat trailing spațiile în linii, uita-te la proprietățile componentei.

Trebuie remarcat faptul că nici un BDE sau dbExpress nu se poate efectua spații de circumcizie la final de liniile.

Domenii de o pată de cerneală

Există subtipuri predefinite (SUB_TYPE) BLOB: 0 - date binare 1 - date text. De fapt, nu există nici o diferență între ele și subtip este relevant numai la cererea dumneavoastră (sau atunci când scrieți filtre BLOB). subtipuri personalizate pot fi determinate prin specificarea SUB_TYPE cu semn negativ - .. -1, -2, -10, -200, și așa mai departe, și din nou, este important numai pentru transmisii de date de operare sau filtru.

segmente BLOB sunt întotdeauna scrise în spațiul liber, și să ia numai volumul real al datelor BLOB.
În cazul în care dimensiunea BLOB este mai mare decât dimensiunea paginii, apoi a crea o serie de indicii la pagina BLOB. La foarte dimensiuni mari pot apărea indicii BLOB BLOB la pagina de index.

La schimbarea de înregistrare, în cazul în care conținutul Blob nu sunt modificate, ea blobID rămâne aceeași. De fapt, în noua versiune sunt înregistrări numai acele domenii care au schimbat în scris. În consecință, atunci când înregistrarea modificării, în cazul în care nu a afectat câmpul BLOB, datele pată de cerneală nu este „duplicat“. În cazul în care se schimbă BLOB versiunea de înregistrare, deoarece este pe disc, în două exemplare - vechi și noi. Luați în considerare acest lucru pentru Blobs care stochează cantități mari de date.

Notă. Pentru a indexa câmpurile BLOB imposibil.







CHAR sau BLOB?

Deci, ne-am luat în considerare toate aspectele legate de date CHAR magazin, și un VARCHAR o pată de cerneală, iar acum se numără liniile directoare pentru alegerea tipului:
  • În cazul în care câmpul de lungime <255 символов, то
    • o mai bună utilizare VARCHAR - varchar de stocare de 2 octeți mai char, dar cererile nu trebuie să scrie de tăiere spațiile rămase în urmă din liniile.
    • în versiunile mai vechi ale IB folosind VARCHAR pot avea probleme de performanță atunci când se utilizează protocolul TCP / IP.
    • Nu are sens să utilizeze un BLOB - prelevarea de probe BLOB efectuate de ID-ul său, astfel încât există un pic mai mult și necesită un pic mai mult decât costul de programare.
  • Dacă lungimea câmpului> 255, dar < 10000 символов
    • Acesta poate fi folosit ca un CHAR sau VARCHAR, și BLOB. Indexarea de domenii de această lungime este imposibil, în plus, există o șansă ca datele înregistrate odată ce depășește 10.000 de caractere, și poate fi BLOB mai potrivesc. Se concentreze doar asupra gradului de utilizare a acestor date în cererea.
  • În cazul în care lungimea câmpului> 5.000 de caractere, sau informațiile pot fi arbitrare
    • o mai bună utilizare a BLOB. Subtip poate fi orice informație în acest domeniu poate stoca un arbitrar și să nu vă faceți griji cu privire la cantitatea de date. Costul de accesare a datelor de această dimensiune este complet compensată diferența în metodele de stocare și extragere a CHAR și BLOB câmpurile de tip.
  • Un factor suplimentar în alegerea ar putea fi o dimensiune de pagină. Când dimensiunea paginii poate fi rând de stocare 8K selectați CHAR sau VARCHAR, în cazul în care lungimea lor, de asemenea, depășește 8K (înregistrare poate traversa pagina, astfel încât chiar și atunci când dimensiunea paginii 1K poate declara 32K rânduri lungi). O idee bună, în astfel de cazuri, pentru a crea un tabel de testare și să încerce să viteza sau ușurința de a citi diferite tipuri de domenii de opțiuni, umplând char, varchar, și blob aceleași date.

conversie de date

Pasărea de Foc și Yaffil, în dialectul treilea a devenit posibil cu insertul (actualizat?) Conținutul Blob pentru a cere linia obișnuită. Restul serverelor în astfel de acțiuni vor fi emise un mesaj standard, cu privire la imposibilitatea de conversie de date.

Cu toate acestea, a existat mult timp o linie de transfer Blob UDF și înapoi (FreeUDFLib și altele).

potențiale probleme

indexare

  • String indiferent de tipul de câmp au o limitare a lungimii indexului - 84 octeți când specificarea COLLATE si 252 bytes - fara COLLATE.
  • BLOB-câmpuri nu pot fi indexate.

Notă. Puteți scrie funcția proprie, similar cu sus și a evita această problemă.

Se preiau datele despre

  • Când concatenand câmpuri șir în interogare trebuie să fie luate în considerare că CHAR-câmp va fi „extins“ la spațiile de lungime specificate, VARCHAR - nr. De exemplu, în cazul în care solicitarea este făcută „adunare“ numelui de familie, numele și patronimicul

selectați LAST_NAME || first_name || middle_name de la clienți

rezultatul este de aproximativ după cum urmează: „Ivanov Ivan Ivanovich“. Și dacă va VARCHAR-câmp, atunci aceeași cerere va da rezultatul ca „IvanovIvanIvanovich“.

Pentru a rezolva această problemă, puteți utiliza UDF pentru CHAR (tip rtrim), iar pentru varchar - se introduce spații suplimentare (|| „“ ||).

  • Pentru BLOB bază de date multilingvă nu poate fi convertit de la o codare la altul. De exemplu, în cazul în care serverul acceptă criptare și WIN1251 KOI8R, și a creat în WIN1251 bază de date, pot fi conectate (prin intermediul unor componente de acces direct) indicând LC_CTYPE = KIO8R în parametrii de conexiune. În acest caz, informațiile vor fi recodate de la win1251 în koi8r și vice-versa pentru toate tipurile de date șir de caractere, cu excepția BLOB. chiar și atunci când proba va trebui să scrie propria UDF pentru conversia blob de date.

Introducerea și modificarea datelor

  • câmpurile BLOB nu pot fi transmise ca parametru de interogare sau o procedură stocată în 2,5x BDE și 3.x (o astfel de posibilitate a apărut doar în BDE 4.0 și y component Delphi 3.0). Acest lucru conduce la nevoia de transmitere a datelor și TQuery un BLOB-câmp prin TBlobStream. Serverul în sine nu are probleme cu obținerea sau transmiterea blob ca parametru de interogare sau proceduri de parametri.

Crearea de baze de date portabile

  • standardul ANSI SQL definește în mod specific tipurile de domenii, dar, desigur, punerea în aplicare a acestor tipuri, o metodă de stocare și prelucrare producătorul determină specific SQL-Server. Pentru a asigura cel puțin o anumită toleranță este posibil, trebuie utilizate tipuri compatibile, ignorând avantajele utilizării tipurilor de date (de exemplu CHAR în Interbase). Trebuie să consultați documentația sau fișiere de ajutor BDE (BDE32.HLP), pentru a determina compatibilitatea între diferitele tipuri de servere SQL-selectate.






anterior ◈ următoarea