Чар или VARCHAR може би петно

Предишен ◈ Следващото

Характеристики на типа низ от данни

Да се ​​повтаря описанието на тези типове данни от документацията (Data Definition) Пътеводител:
  • CHAR (п) - п символи, от 1 до 32 767, фиксирана дължина тип низ. Ако съдържанието на полето е по-малко от определения размер, той е "изравнени" (не постига) допълнителни пространства.
  • VARCHAR (п) - п символи, от 1 до 32767, тип променлива дължина низ. Spaces в края на съдържанието на полето се игнорират.







Максималната дължина на типа низ зависи от набор от символи. знаци са посочени в Ръководството за данни Defintion (Приложение А) и за езика (Приложение D). За всеки набор показва броя на байтове, взети от един символ. Ако един набор от знаци заема повече от един байт, максималната дължина на полето низ е 32 767 / Брой vo_bayt_na_simvol (т.е. за UNICODE_FSS - .. 10922 знака).

На записа на диск винаги е пълен. Това означава, че крайните интервали не са от значение за перспективата на дисково пространство.

Брой на интервалите се взема под внимание само на VARCHAR. Стойността на Чар "търси" с интервали по дължината обявени само когато с него, направено от назначение или предаване на данни от страна на клиента.

Ето защо, от гледна точка на ефективност разлика между съхранение Чар и VARCHAR на практика няма. И да работят трябва да изберете това, което е по-удобно. Обикновено това е VARCHAR.

Клиентски компоненти могат (или не може) да извършват обрязването за крайни празнини CHAR колони. В зависимост от наклона на разработчик пропуски комплект обрязването може да бъде по подразбиране и може да изискват монтиране на True всяко имущество или DataSet равнище или на равнището на конкретната област (TStringField). Ето защо, ако измъчван интервалите в линии, погледнете свойствата на компонента.

Трябва да се отбележи, че нито BDE или dbExpress не може да изпълнява обрязване интервалите от линиите.

Сфера на петно

Има предварително определени подтипове (SUB_TYPE) BLOB: 0 - двоични данни 1 - текстови данни. В действителност няма разлика между тях и подтип се отнася само за вашето приложение (или когато пишете BLOB филтри). Персонализирани подвидове могат да бъдат определени чрез определяне SUB_TYPE с отрицателен знак - .. -1, -2, -10, -200, и така нататък, и отново е важно само за приложения работни данни или филтър.

BLOB сегменти винаги са написани на свободното пространство, и да вземат само на действителния размер на данните петно.
Ако размерът на BLOB е по-голям от размера на страницата, а след това се създаде масив от указатели към страницата на BLOB. В много големи размери може да не BLOB BLOB указатели към индексната страница.

При смяна на записа, ако съдържанието на петно, не са се променили, то blobID остава същата. В действителност, в новата версия са написани записи само тези полета, които са се променили. Следователно, при запис на промяната, ако не се влияе поле BLOB, петно ​​данни не е така "дублира". Ако петното се променя версията на протокола, тъй като е на диска в два екземпляра - стари и нови. Помислете за това за петна, които съхраняват големи обеми от данни.

Забележка. За да индекс областта петно ​​невъзможни.







CHAR или BLOB?

Така че, ние имаме предвид всички аспекти на данните от магазин CHAR, VARCHAR и петно, а сега може да се изброят насоки за избора на типа:
  • Ако полето за дължината <255 символов, то
    • по-добро използване VARCHAR - VARCHAR съхранение 2 байта вече Чар, но приложенията, не е нужно да пиша рязане интервалите от линиите.
    • в по-старите версии на IB, използващи VARCHAR може да има проблеми с производителността при използване на TCP / IP протокол.
    • То няма смисъл да се използва BLOB - вземане на проби BLOB извършва по идентификационния му номер, така че има малко по-дълго и изискват малко повече от разходите за програмиране.
  • Ако дължината на полето> 255, но < 10000 символов
    • Тя може да се използва като CHAR или VARCHAR и BLOB. Индексирането на сфери на тази дължина е невъзможно, освен това, има шанс, че след като записва данни надхвърля 10,000 знака и може да бъде BLOB поберат повече. Съсредоточете се само върху използваемостта на тези данни в заявлението.
  • Ако дължината на областта> 5000 знака, или информацията може да бъде произволно
    • по-добро използване на BLOB. Подтип може да бъде всякаква информация в тази област може да се съхранява произволно и не се тревожи за количеството данни. Цената на достъп до данните на този размер е напълно компенсирани за разликата в методите за съхранение и извличане на CHAR и BLOB полета тип.
  • Допълнителен фактор при избора може да бъде размера на страницата. Когато размерът на страницата може да бъде 8K ред съхранение изберете CHAR или VARCHAR, ако тяхната дължина да надвишава 8K (запис може да премине на страницата, така че дори когато размерът на страницата 1K може да обяви 32К редове дълго). Добра идея в такива случаи, за да създадете таблица тест и се опитват да скорост или по-лесно четене на различни видове опции полета, попълване Чар, VARCHAR, и петно ​​и същи данни на.

преобразуване на данните

Много популярни и зелен кълвач, в третия диалект става възможно с вложка (актуализирам?) Съдържанието на петното да задават обичайните линия. Останалата част от сървърите, в подобни действия, ще бъде издаден на стандартно съобщение за невъзможността на преобразуване на данните.

Въпреки това, съществуват отдавна е прехвърляне линия петно ​​СДС и обратно (FreeUDFLib и други).

потенциални проблеми

индексиране

  • String, независимо от вида на полето да има ограничение на продължителността на индекса - 84 байта, когато уточняват събира и 252 байта - без съпоставя.
  • BLOB полета не могат да бъдат индексирани.

Забележка. Можете да напишете своя собствена функция, подобна на горната, и да се избегне този проблем.

Извличане на данни

  • Когато слепване низови полета в заявката трябва да се счита, че ЧАР-област ще се "разшири" до посочените пространства дължина, VARCHAR - не. Например, ако заявката е направена в "сглобяването" на фамилия, име и фамилното име

изберете last_name || || first_name middle_name от клиенти

резултатът е приблизително по следния начин: "Иванов Иван Иванович". И ако това ще VARCHAR поле, а след това същото искане ще даде резултат като "IvanovIvanIvanovich".

За да се реши този проблем, можете да използвате СДС да CHAR (тип RTRIM), а за VARCHAR - вмъкнете допълнителни интервали (|| "" ||).

  • За многоезичен BLOB база данни не може да бъде изчислена от един кодиране на друг. Например, ако сървърът поддържа криптиране и WIN1251 KOI8R, и е създадена за WIN1251 база данни, могат да бъдат свързани (чрез преки компоненти за достъп) сочи LC_CTYPE = KIO8R в параметрите на свързване. В този случай, информацията ще бъде рекодират от WIN1251 в koi8r и обратно за всички видове низ от данни, с изключение на BLOB. дори и когато пробата ще трябва да напишете своето собствено СДС за конвертиране петно ​​данни.

Поставяне и модификация на данните

  • BLOB области, които не могат да се предават като параметър на заявката или съхранена процедура в BDE 2.5x и 3.x (такава възможност се появи само в BDE 4.0 и у компонент Delphi 3.0). Това води до необходимостта за предаване на данни и TQuery петно ​​поле през TBlobStream. Сървърът се има проблеми с получаване или предаване петно ​​като параметър на заявката или параметри процедури.

Създаване на база данни преносим

  • ANSI SQL стандарт конкретно определя вида на полета, но, разбира се, прилагането на тези видове, метод за съхранение и обработка производителят определя специфични SQL-сървър. За да се осигури най-малко известна толерантност е възможно трябва да се използва видове съвместими, без да обръща внимание на предимствата от използването на типове данни (например CHAR в InterBase). Трябва да се консултирате с документацията или помощни файлове BDE (BDE32.HLP), за да се определи съвместимостта между различните видове вашите избрани SQL сървъри.






Предишен ◈ Следващото