Linux за българи: Форуми

Предварително държа да отбележа че хич ме няма в тази област.  ;D

На теория да кажем имаме база данни от 3 таблици, чиято цел е да държи инфо за даване на апартаменти, коли, каки или каквото друго се сетите под наем. Примерно:

Апартаменти
 - ID
 - адрес
 - кв.м.
Клиенти
 - ID
 - Име
 - Фамилия
Поръчки
 - ID
 - Клиент_ID
 - Апартамент_ID
 - начало на наем (дата)
 - край на наем (дата)

На пръв поглед - възможно най-простата М:N структура. Трите ID-та като Primary Keys, Клиент_ID и Апартамент_ID като Foreign Keys, останалото ясно. Да кажем обаче че в тази БД се правят заявки само върху наемите - т.е. от днес до другиден примерно търсим свободни апартаменти. В случая се получава малко кофти, понеже в третата таблица имаме 3 полета с индекси и 2 полета без, като търсим точно според тези без индекси.

Да приемем и че базата е доста голяма. В задачката се пита как да организираме цялата работа така че да направим възможно най-бързото търсене. Т.е. оставяме всичко така както си е, слагаме индекси и на последните две полета, или правим други магически трикове?  ;D

Отбелязвам и че не става въпрос за домашно или курсова работа, просто ми е любопитно какво е мнението на човек който е по-навътре в нещата :)

Аз на прима виста се сещам за един грозен хак. Да си отделиш датите в отделни полета който да не са тип datetime, а smalint и примерно да имаш : start_year, end_year, start month, end_month, start_day и end_date. Но това за мен лично е работещо и в същото време грозно решение. Потърси в нета, не си първия задал този въпрос.

Тук има нещо интересно : http://hackmysql.com/case2

Няма нужда да ги делиш на каквото и да било, тип char( 8 ) и формат на запис yyyymmdd е напълно достатъчен. Първо като едно текстово поле си се индексира чудесно и две работи перфектно със

GeSHi (SQL):
SELECT * FROM MY_TABLE WHERE SOME_DATE BETWEEN '20130301' AND '20130331';
SELECT * FROM MY_TABLE WHERE SOME_DATE > '20130301';

Разбира се малко допълнителен код трябва за да форматираш датите.

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

1. какво е вашето виждане за голяма база, 100 милиона реда, 10 милиарда реда?
2. както отбеляза jet, не е задължително да имате индекс за да търсите по колона
3. както sudo грешно предложи има си типове дата с които базата си работи великолепно, да не говорим че формата, който sudo е предложил е много лош, ако ще сортираме YYYYMMDD е много по-добър

10 млрд. аз лично я броя малка, сляд като толкова държи дори сялите.

Нещо не разбрах личното отношение, но ще го пропусна.
Мразя да пиша реферати, но явно ще трябва да се обясни подробно като за имбецили. Никъде не съм казвал да не се ползва тип данни "Дата" или сродни, казах че няма смисъл да правим отделни полета за година, месец, ден като може всичко да се събере в едно поле. Разлика м/у yyyymmdd и YYYYMMDD аз виждам само в регистъра на изписването ако някой вижда нещо друго ... и не на последно място въпроса беше "В задачката се пита как да организираме цялата работа така че да направим възможно най-бързото търсене. Т.е. оставяме всичко така както си е, слагаме индекси и на последните две полета, или правим други магически трикове?" книжките които аз съм чел за SQL казват че индексите ускоряват търсенето, което пита и колегата.

Судо, това което пишеш е точно така, само не разбрах, къде видя лично отношение?

Судо, това което пишеш е точно така, само не разбрах, къде видя лично отношение?

Тебе редник те обичам  [_]3 ... че иначе модератора ... >:D

Нещо не разбрах личното отношение, но ще го пропусна.
Мразя да пиша реферати, но явно ще трябва да се обясни подробно като за имбецили. Никъде не съм казвал да не се ползва тип данни "Дата" или сродни, казах че няма смисъл да правим отделни полета за година, месец, ден като може всичко да се събере в едно поле. Разлика м/у yyyymmdd и YYYYMMDD аз виждам само в регистъра на изписването ако някой вижда нещо друго ... и не на последно място въпроса беше "В задачката се пита как да организираме цялата работа така че да направим възможно най-бързото търсене. Т.е. оставяме всичко така както си е, слагаме индекси и на последните две полета, или правим други магически трикове?" книжките които аз съм чел за SQL казват че индексите ускоряват търсенето, което пита и колегата.

За формата на датата се извинявам, явно рано сутрин очите ми недовиждат.
А за индексите - и да и не, зависи от конкретния софтуер

А за индексите - и да и не, зависи от конкретния софтуер

Колега, говоря за принципната постановка, че индексите се използват за оптимизиране работата на БД.
Иначе и двамата, а най-веротно и други, знаем че една по-засукана WHERE клауза може да обезмисли индексите.  [_]3

извън темата

---

Цитат на: go_fire в Mar 24, 2013, 11:09

Судо, това което пишеш е точно така, само не разбрах, къде видя лично отношение?

Тебе редник те обичам  [_]3 ... че иначе модератора ... >:D

Sudo нещо си в грешка. Аз не съм любимец на модераторите. Когато нарушавам правилата, а това е горе-долу често, мен също ме модерират. Не се ползвам с никакви предимства пред кой да е друг потребител. Случвало се е да ме модерират и когато съм мислел, че съм написал нещо с пълно основание, но поради странични ефекти или други причини, които не са ми били съобщавани, съм бил все пак модериран.

Тъй че няма от какво да се притесняваш, да ми кажеш каквото и да е, ако трябва на ЛС. Но аз продължавам да не виждам лично отношение, че и да се засягаш.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

off

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

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

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

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

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

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

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

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