Изпечатай

[romeo_ninov]

Аз бих сложил фалшиви дати (напр. 32.13). И после в логиката на приложението, като хвана такава, просто я изчиствам и мястото ѝ остава празно или го заменям с питанка, та да се знае от четящият, че това е неизвестна информация. А може и да не съм чак толкова оргинален и за всяка информация, която не ми е известна да праскам нули и като се натъкна на нуличка, ми става много по-лесна филтрацията, отколкото за истинска дата, което не е също трудно, ако се ползва готова библиотека. По единият или другият начин, аз бих реализирал задължително логика за проверка на възможни дати, защото смятам, че това е добра практика. Фактически може да се мине без това, но по моите разбирания, си трябва.

По твоите разбирания може това да е разумно, но от гледна точка на базите данни това са недомислици, да не кажа по-силна дума. Нали се сещаш какво ще стане като се опиташ да вмъкнеш дата, която е невалидна в таблицата?

[go_fire]

Първо аз говорех в логиката на приложението. А относно базите, за разлика от теб не съм виждал никакви оракули, нито дб2. Моите сили стигат до мъсял. Там датите е най-добре да се запазват като целочислен тип (заради бързина). В повечето случай (без разглежданият тук) е добре да се ползва юниксово време, а не някой от вградените типове (пак заради бързина).

И така като нашляпам в базата дата 20031234 ми ставя ясно, че тридесет и четвърти е невъзможен и го заменям с питанка. Декември и годината са възможни, значи си отиват на местата в съответните полета.

Разбира се, още е добра практика, още на ниво база да получиш готовата информация, а не да я дообработваш и всъщност да получаваш, и излишна информация. Но точно в този случай не виждам по-добро.

Твоя вариант с еденици, не виждам как да го реализирам, защото нова година е валидна дата и на нея могат (и са много чести) да се провеждат представления.

[angie_bg]

В момента базата е на хартия. Данните са в електронна таблица, като:
- липсваща дата = 01
- липсващ месец = 01
- липсваща година, но се знае сезона -  01.01.2001 (при сезон 75 ~ 01.08.2000 до 01.08.2001)
освен това в отделна клетка поставям знак:
! - уточнена дата;
? - неуточнена;
<, > - преди, след датата.
Това решение върши работа, но не ми се струва много елегантно.

[go_fire]

Аха и в заявката вкарваш „когато“ с един от два варианта. Добре, ама пак идва излишна информация от базата, а имаш и две допълнителни полета. Добре, ама не ми е ясно, как от това допълнително поле с чуденки и питанки, разбираш точно кое от трите числа е фалшивото. А то може да е комбинация от две числа или дори всичките, ако изобщо си нямаме понятие, коя е датата.

А Ве този проект как е още на хартия? Още преди година поне тук беше пуснал един въпрос за речниците, как в тях може да има безумна дума, а друга безумна да я няма, като и двете бяха от името на представление.

[romeo_ninov]

Първо аз говорех в логиката на приложението. А относно базите, за разлика от теб не съм виждал никакви оракули, нито дб2. Моите сили стигат до мъсял. Там датите е най-добре да се запазват като целочислен тип (заради бързина). В повечето случай (без разглежданият тук) е добре да се ползва юниксово време, а не някой от вградените типове (пак заради бързина).

И така като нашляпам в базата дата 20031234 ми ставя ясно, че тридесет и четвърти е невъзможен и го заменям с питанка. Декември и годината са възможни, значи си отиват на местата в съответните полета.

Разбира се, още е добра практика, още на ниво база да получиш готовата информация, а не да я дообработваш и всъщност да получаваш, и излишна информация. Но точно в този случай не виждам по-добро.

Твоя вариант с еденици, не виждам как да го реализирам, защото нова година е валидна дата и на нея могат (и са много чести) да се провеждат представления.

Ти защо не ги направиш всички полета int или long int? Или направо да си ползваш текстови файл вместо база?

В момента базата е на хартия. Данните са в електронна таблица, като:
- липсваща дата = 01
- липсващ месец = 01
- липсваща година, но се знае сезона -  01.01.2001 (при сезон 75 ~ 01.08.2000 до 01.08.2001)
освен това в отделна клетка поставям знак:
! - уточнена дата;
? - неуточнена;
<, > - преди, след датата.
Това решение върши работа, но не ми се струва много елегантно.

Като идея помислете дали да не е число, сравнението на числа е обикновено по-бързо от това на стрингове. Иначе да, това с индикатора е много добра идея и не мисля че прави структурата грозна или неправилна

Аха и в заявката вкарваш „когато“ с един от два варианта. Добре, ама пак идва излишна информация от базата, а имаш и две допълнителни полета. Добре, ама не ми е ясно, как от това допълнително поле с чуденки и питанки, разбираш точно кое от трите числа е фалшивото. А то може да е комбинация от две числа или дори всичките, ако изобщо си нямаме понятие, коя е датата.

Елементарно е, имаш 4 полета, които са да или не: дата, месец, сезон (виж примера по-горе) или година. И колко са вариантите?

[go_fire]

Не е всичко int, защото има данни, които не са числа Така де, ако не обработвам някакви статистически данни, най-малкото ще имам и някакъв текст нали?

Явно не съм разбрал. Мислех, че идеята е да махнем трите полета за части от датата и да набутаме датата в само едно поле.

[romeo_ninov]

Не е всичко int, защото има данни, които не са числа Така де, ако не обработвам някакви статистически данни, най-малкото ще имам и някакъв текст нали?

Явно не съм разбрал. Мислех, че идеята е да махнем трите полета за части от датата и да набутаме датата в само едно поле.

Човече, да не си опериран от чувство за хумор? Чувал ли си какво е ирония? С това да направиш всичко целочислено те иронизирах за това че бягаш като от огън от поле тип дата. И да, събирам ги в една колона, и то от различен (нативен за данните) тип

[go_fire]

На теб ти е добре известно, че съм ламер и за три живота, няма да имам и стотна от знанията ти. Но тук говоря единствено и само за случая мъсял, защото Анджи 99% ще използва точно него. Заданието е студентска задачка. В мъсял, това го знам от наистина сериозни разработчици, работещи за много сериозни пари по много сериозни международни проекти, че специално типовете за дати са непропоръчителни от гледна точка бързодействие.

Аз нямам възможност да правя изпитания за потвърждение или отхвърляне на тезата, но тези хора са ги правили тия неща, защото когато в един проект участват три западни държави, всичко се изпипва, не се остава на случайност нищо. Нямам причина да не им вярвам.

[romeo_ninov]

На теб ти е добре известно, че съм ламер и за три живота, няма да имам и стотна от знанията ти. Но тук говоря единствено и само за случая мъсял, защото Анджи 99% ще използва точно него. Заданието е студентска задачка. В мъсял, това го знам от наистина сериозни разработчици, работещи за много сериозни пари по много сериозни международни проекти, че специално типовете за дати са непропоръчителни от гледна точка бързодействие.

Аз нямам възможност да правя изпитания за потвърждение или отхвърляне на тезата, но тези хора са ги правили тия неща, защото когато в един проект участват три западни държави, всичко се изпипва, не се остава на случайност нищо. Нямам причина да не им вярвам.

Не мога да твърдя за MySQL, не съм се интересувал. Но защо си мислиш че не могат да ползват Oracle, DB2. Всяка от тях има и безплатна версия, разбора се с известни ограничения като РАМ, която ползва и/или брой процесорни ядра и/или обем на базата. Но за такива проекти нито едно от тези ограничения не е съществено.
Освен това аз тенденциозно попитах за това колко е дълбока базата. Ако говорим за стотици милиони или даже десетки милиони то тогава твоята забележка би имала място. Но ако говорим за десетки или стотици хиляди разликата във времената ще е несъществена

[angie_bg]

@go_fire, като казвам на хартия, имам предвид, че базата, която както правилно си предположил, е MySQL и е само на моя комп, няма интерфейс, заявките ги правя от конзола. Вкарал съм 10 000 реда, колкото за тестване. Останалото е в таблица и чака. Мога да променям структурата както си искам, затова питам за оптимален вариант. Въпросът с речника също беше мой. Обемът на базата на първо време ще е около 200 000 записа, а после ще видим.

[go_fire]

То защото помня, че беше твой. Имаш афинитет към речниците и си създал един от двата най-уникални речника дето съм виждал (другият е на врачанските говори).

Ами вече споменах, как аз бих го сторил. При моя вариант и заявките са по-прости (съответно по-бързи). 200 х. не е много, ама на слаба машина или българските споделени домувания дето за чеп не стават, то си оказва влияние.

Аз наистина не знаех, че ДБ2 и Оракул имат безплатни версии, знам само за М$, ама тяхното не върви на истинска ОС, та е изключено по подразбиране. Но дори така ламер като мен, не би ги ползвал. След като един обикновен Постгрес се оказва страшно непреоделимо препятствие, какво да си говорим за батковците.

[laskov]

Проблемът е, че често датите не са напълно уточнени:
- преди 1987 г. - тогава е имало статия, че постановката е минала, месец и дата не са ясни;
- през март 1993 г. - т. е. месецът и годината са ясни, но денят - не.
и др. подобни
Въпрос: кой ще е най-добрият начин за въвеждане на данните? Предложеният от Drago_? Вариантът на sudo ще работи ли, и ако да - как ще се филтрират/сортират "20030312" и "200303"?

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

[edmon]

off

След като един обикновен Постгрес се оказва страшно непреоделимо препятствие, какво да си говорим за батковците.

на постгре и майскюел може да гледаш както на линукс и уиндоус .

[NorthBridge]

Освен това аз тенденциозно попитах за това колко е дълбока базата. Ако говорим за стотици милиони или даже десетки милиони то тогава твоята забележка би имала място. Но ако говорим за десетки или стотици хиляди разликата във времената ще е несъществена

Целия ми въпрос беше в полето на теорията, така че нека приемем че вътре има 1 милиард записа и ще се усети разлика в търсене с индекс и без.

Направих малко ровичкане в Google и установих че кажи-речи всички избягват да ползват DATETIME за тип данни и вместо това слагат TIMESTAMP за да избегнат проблеми с часовите зони каквито биха се появили при INT поле, стига да не се налага да излизат извън обхвата на щампите.

Освен всичко това навсякъде се говори, че е лоша идея да се слагат индекси на всяко едно поле от една таблица и ако се наложи да се направи, нещо в цялата структура не е добре. Затова и питах кой е най-добрия вариант от гледна точка на бързодействие

В този ред на мисли има ли резон да се разкара полето ID и вместо него да се сложат двете полета за данни като Compound Primary Key?

[jet]

пак ти казвам, не се занимавай с тези индекси. Дори и като ги няма, ДБ енджина си прави вътрешни индекси без да знаеш за тях. Ти гледай да не правиш глупави SQL заявки и всичко ще е наред. Като се натрупа база, има инструменти да видиш къде са ти тесните места и да оптимизираш. Индекси се слагат и махат с една команда.