Sveikas,

    Nelabai supratai manes, teke kazkada daryti rysi su pvz. Navision tai ten visur raktai stringai, del to nieko as blogo nesakau, jei jau kalbant apie rimtus raktus tai mano nuomuone GUID geriausia, ipac kalbant apie MSSQL, kur jie poto gali buti reusinti replikavimui ir tuo paciu buti ID.

    Pirmas dalykas as neminejau nieko kad as pries stringus, o klausimas buvo konkreciai  kodel naudojamas butent char!

    Jeigu konkreciau, kalba apie tai kuo remiantis naudojamas CHAR arba NCHAR, o ne varchar ar nvarchar, kur char visada atlieka tarpais jo nurodyto ilgio islyginima, jeigu laukas bus CHAR(10) ir ivesta bus i ji '1' tai jis ji duomenu bazeje pavers i '1         ' - kas veliau pridaro labai daug bedu ir nekalbu apie tokio lauko pastovu RTRIM'inima ir kitas problemas kuriant sistemas su panaudotais xCHAR o ne xVARCHAR tipais.

    Esu ne karta susidures su pradinuku ar megeju architekturomis kur prideda be jokios priezasties CHAR tipus, o poto lenda bugas ant bugo ir jei toki sutikciau tai per nagus gautu kaip reikalas uz tai... 

    Pvz buvo atvejis, programuotojas sukure sistema ir duombazeje naudota pastoviai CHAR tipas, poto jis su .NET String.Trim metodu trimmina tarpus pries teksto paieska kur, del vienos klaidos pasirenkant bloga duomenuu tipa glimsta dar i didesnes problemas, nes pradeda naudoti String.Trim, sis metodas trimins visus tarpus, o ne vien nereikalingus nuo galo ir rezultate pvz. tekstas:

string compare1 = "ABCDE        ";
string compare2 = "ABC DE ";

Po Trim funkcijos bus vienodas, tas liecia ir duomenu baze!

===========================================================

   Pirmas dalykas kas yra kas:
----------------------------------
    CHAR            - duomenu tipas skirtas laikyti NE unicode(utf) informacijai, kurio tuscia vieta issaugojus jame ka nors visada uzpildoma tarpo kodais, kad islyginti duomenu ilgi iki maksimalaus nurodyto lauko ilgio, sio lauko kilme labai sena ir jis kilo dar nuo space delimited tekstiniu duomenu baziu, kur islyginimu iki maksimalaus nurodyto lauko ilgio buvo pasiekiamas didesnis performance ;

    VARCHAR    - taip pat ne unicode duomenu tipas skirtas laikyti tekstui, taciau laiko tik tiek teksto kiek buvo jame issaugota, nedaro jokiu uzpildymu papildomais simboliais iki maksimalaus lauko ilgio;

    NCHAR         - analogiskas CHAR tipui tik skirtas laikyti unicode informacijai;

    NVARCHAR - analogiskas VARCHAR tipui tik skirtas laikyti unicode informacijai;



    Toliau kas nezino ka naudot siulyciau laikytis maniskiu taisykliu:
---------------------------------------------------------------------
    1. Niekada nenaudoti CHAR, NCHAR tiesiog kaip tekstinio tipo - be tikrai svarbios priezasties ir vien tik is tingejimo kad kuriant DB lentele grafineje char combobox sarase bus pirmas;

    2. Jeigu jusu DB klientas tai .NET Application ar ASP.NET (.NET by default visus stringus laiko Unicode'u) ar kitas web puslapis naudojantis UTFx ar Unicode, visada reikia rinktis unicode'ini duomenu tipa o ne paprasta, informacija kad ir su paprastu UTF uzims daugiau vietos ir pvz i varchar(10) gali netilpti 10 simboliu tekstas...


    varchar ar nvarchar yra ir taupesni ir sudarantys ateityje maziau bedu, tiesiog jei bus daroma paieska, ivairus sulyginimai tai teks kiekviena kart SQL poto nepamirst RTRIM, o atvejai kada realiai reikia CHAR ar NCHAR yra labai reti ir daznai susija kaip tik su kiek didesniu Low leveliu!

    
    Nepatingejau parasyti, nes ne karta teko susidurti su sistemom kur zmones is nesupratimo dare klaidas ir labai juos del to ilgai ir nuobodziai keikti, bei poto visa duombaze taisyti ir grybu pripjauta koda, del to Учись студент! Gal maziau teks susidurti poto su tokiais sedevrais :)

JDM.
---------------------------
Freelancer programmer
www.lythum.lt



"IF" <nojauslaivas@gmail.com> wrote in message news:hk1dj9$1mr$1@trimpas.omnitel.net...
> Kai labai senais, senais, akmens amziaus laikais,buvau jaunas ir durnas ir 
> programavau asembleriu, taip pat maniau kad laukai turi ristis, grieztomis 
> primary - secondary key, number strukturomis. bet laikai keiciasi, niekas 
> nestovi vietoje vyksta progresas ir nauji gyvenimopoziuris ir manau kad 
> pasikeitus ateiti hardvarui, sis STRING risys tik tobules :)
> 
> Juk lentu tarpusavio risys, taip pat risys tarp objektu, ne tiesa Jordanai, 
> o kodel ir cia nepanaudojus stringo :), o dar plius kaip matome apkabineto 
> logiskomis duomenu transformaciju klasemis ;)
> 
> "Jornada Del Muerto" <ask@me.email> wrote in message 
> news:hju5sg$kk0$1@trimpas.omnitel.net...
>> da... o char naudojimo kokia priezastis? paprastai neleisciau to daryt 
>> jokiam programeriui be tikrai svarbios priezasties...
>>
>>> char(x)
>>
>>>> koks lauko, i kuri insertini tipas DB?
>> 
> 
>