Қай деректер түрін пайдалану керек: таңба немесе бүтін сан

Новости мира

Бұрын, FoxPro бағдарламасында сандық деректерді сақтау үшін тек Сандық типті өрістер болған кезде, аргументтің басымдылығы Таңба типі өрістерін пайдаланудың пайдасына бейім болды, бірақ бүтін типті өрістердің пайда болуымен нәрселер анық емес болды.

Кілттік өрістің таңбалық немесе сандық форматта қалай сақталатынын салыстыру кезінде 3 аргумент ұсынылады.

Сандық өрістерде жаңа мән қалыптастыру оңайырақ
Таңба өрістері «үнемдірек», яғни. бірдей өлшемде көбірек мәндерді сыйдыра аласыз
Таңба өрістері репликация деп аталатын тапсырмалар үшін «әмбебап» болып табылады, яғни. байланысы жоқ мәліметтер қорын біріктіру

Сандық өрістерді қалыптастыру оңайырақ

Мұнда сандық өрістер бәсекелестікке жатпайды, себебі сандық кілт өрістерін қалыптастырудың стандартты жолы «максималды мән плюс бір» болып табылады. Таңбалық өрістер жағдайында, әдетте, псевдокездейсоқ сандар генераторы қолданылады. Бұл таңба пернелерінің жасалу жолын талқылайтын орын емес, бірақ шын мәнінде бірегей мәнді қамтамасыз ету қиындығына байланысты қатысатын процедуралар әдетте өте күрделі.

Жаңа кілт мәнін жасау үшін ағымдағы кестедегі максималды мәннің анықтамасын пайдалану қажет емес екенін де ескеремін. Бұл бір пайдаланушы режимінде жақсы, бірақ көп пайдаланушы режимінде екі пайдаланушы бір уақытта жаңа жазба қосқанда 2 бірдей негізгі мәнді алу қаупі бар. Әдетте, соңғы пайдаланылған (немесе бірінші пайдаланылмаған) кілт мәнінің мәнін сақтайтын арнайы қызмет көрсету кестесі пайдаланылады. Мұндай кестені пайдалану мысалдары стандартты FoxPro мысал жобаларында берілген: Solution.pjx (NewID.scx пішіні) және TasTrade.pjx. Ал FoxPro-ның 8-нұсқасында бұл тапсырманы толығымен жеңілдететін автоматты ұлғайту өрістері пайда болды.

Таңба өрістері «үнемдірек», яғни. бірдей өлшемде көбірек мәндерді сыйдыра аласыз

Сұрақтан бастайық, кестедегі барлық жазбаларды анықтау үшін қанша мән қажет?

Жүйе шектеулерінен біз DBF кестесіндегі жазбалардың ең көп рұқсат етілген саны 1 миллиард жазба (1 миллиард) екенін білеміз. Анау. бұл бірден кейін тоғыз нөл

Integer түріндегі өріс -2,147,483,647 мен 2,147,483,647 аралығындағы мәндерді қабылдай алады. Теріс мәндер әдетте пайдаланылмайды, бірақ оң мәндер жазбалардың максималды санынан 2 есе көп. Жазбаларды жою мүмкіндігін ескере отырып — дәл солай.

Бүтін типті өріс физикалық түрде 4 байт (4 таңба) алатындықтан, таңба өрісі үшін бірдей өлшеммен қанша мән тағайындауға болатынын көрейік.

Бір байтта 256 мән жазылуы мүмкін, яғни. бұл 256**4=4,294,967,296 болады. Бірақ кейбір мәндерді бірқатар себептер бойынша (мысалы, жаңа жол таңбасы, Esc және т. Caracter(4) түріндегі өрістен төмен, мүмкін, тіпті сәл жоғарырақ

Түсініктеме

Айта кету керек, Сандық өрістер FoxPro бағдарламасында символдық өрістер ретінде сақталады, яғни. әр цифрды сақтау үшін бір байт қажет. Бұл дегеніміз, егер осы кестедегі мәндердің күтілетін саны мыңнан аспаса (4 таңбадан аз), онда «сақтау» азғыруы бар және Integer түрінің орнына, айталық, түр өрісін енгізіңіз. N (2)

Сондықтан мен мұны келесі себептерге байланысты жасауға кеңес бермеймін:

Қазіргі компьютерлерде кестелердің физикалық өлшемі (байтпен) бұрынғыдай іргелі рөл атқармайды. Сіз дискілік кеңістікті көп үнемдей алмайсыз.
Егер барлық кестелердегі барлық негізгі өрістер бірдей деректер түрі мен өлшеміне ие болса, онда бұл бағдарламалау процесінің өзін айтарлықтай жеңілдетеді. Белгілі бір кестеде қандай түр мен өлшем қолданылғанын дәл есте сақтаудың қажеті жоқ. Кейде бұл принципті маңызды болып табылады.

Таңба өрістері репликация деп аталатын тапсырмаларда «әмбебап» болып табылады

Репликация – бір-бірімен байланысы жоқ екі дерекқордан, мысалы, бір ұйымның бір-бірінен географиялық тұрғыдан қашықтағы екі филиалынан алынған ақпараттың қосындысы.

Иә, шынында да, мұндай тапсырмаларда символдық өрістерді пайдалану ыңғайлырақ, дегенмен мұндай жоғалған жағдайда да сандық өрістерде «дауласу» бар.

Бұл мәселені оның ауқымдылығына байланысты талқылайтын орын емес, сондықтан мен тапсырмалардың өте үлкен ауқымы үшін репликация тапсырмасының өзі маңызды емес екенін ғана атап өткім келеді. Не файл-сервер технологиясы пайдаланылады, немесе сілтемелер мен есептерді алу үшін біріктіру тек бір бағытта қажет
Қорытынды суррогат кілттеріндегідей категориялық емес:

сандық кілт үшін жаңа мәнді жасау таңбалық кілт үшін жаңа мәнді жасаудан оңайырақ
Integer және Cracter(4) типтері үшін кілт мәндерінің саны дерлік бірдей
күрделі репликация тапсырмаларын шешу кезінде символдық перне өрістерін пайдалану ыңғайлырақ
Бірақ көптеген бағдарламашыларға репликация тапсырмаларымен айналысуға тура келмейтіндіктен, негізгі өрістер үшін Integer түрін қауіпсіз пайдалануға болады.

Барлық кестелерде ерекшеліксіз кілттік өрісті пайдалану қажет пе?

Бір қарағанда сұрақ оғаш көрінуі мүмкін. Негізгі өріссіз мүмкін бе? Кейбір жағдайларда мүмкін болады екен.

Мысалы, «көптен көпке» қатынасын ұйымдастыру үшін стандартты әдіс – делдалдық кестені құру. Нені білдіреді?

Сізде контрагенттер тізімі мен банктер тізімі бар делік. Әрине, бір контрагенттің бірнеше банкте шоты болуы мүмкін. Бірақ керісінше де дұрыс – бір банк бірнеше контрагенттермен жұмыс істейді. Бұл жағдайда контрагент кестесінде банктің сыртқы кілтін немесе банктер кестесінде контрагенттің сыртқы кілтін жасай алмайсыз. Банктің сыртқы кілтін және контрагенттің сыртқы кілтін сақтайтын делдалдық кестені енгізу керек.

Мұндай ұйыммен осы аралық кестедегі әрбір жазба мәндер жұбы арқылы бірегей түрде анықталады: контрагент коды-банк коды. Сондықтан осы прокси кестесінің суррогат кілті үшін басқа өрісті енгізбеу қызықтырады.

Дегенмен, барлық дерекқор кестелері үшін өз кілт өрісіңізді енгізуді ұсынамын. Неліктен? Өйткені, кез келген бағдарламаның дамытатын «әдісі» болады.

Егер контрагенттермен және банктермен мысалға оралсақ, мен бір контрагенттің бір банкте бірнеше шоты болуы мүмкін деген тармақты елемегенімді байқау қиын емес. Дәл осы реквизит (контрагенттің банктегі шоты) банкке де, контрагентке де тіркеле алмайды. Бірақ ол осы аралық үстелге өте жақсы сәйкес келеді. Осы кестедегі жазбаны анықтау үшін мына жұпқа сүйенетін болсаңыз: банк коды — контрагент коды, онда сізге бағдарламаның маңызды бөлігін байыпты түрде қайта жасау керек болады. Ал өзіңіздің жазу кодыңыз болған жағдайда ешқандай проблемалар болмайды. Олар тағы бір өрісті қосты, сонда ше?

Бұл жағдайда мен өте айқын жағдайды қарастырдым, бірақ көбінесе бұл басқаша болуы мүмкін емес сияқты көрінеді, тіпті мұнда сіздің жеке жазба идентификаторыңыз қажет емес. Алданбаңыз. Егер сізге бірдеңе болуы мүмкін емес сияқты көрінсе, бұл сіздің бір нәрсені білмейтіндігіңізді білдіреді.
Қорытынды – барлық кестелерде өзіңіздің кілттік өрісіңізді ерекшеліксіз пайдаланыңыз. Сіз онсыз жасай аламын деп ойласаңыз да.