Він у типовий пошук входить?
Прикро, а можна якось цю кількість регулювати або збільшити?
а навіщо взагалі це обмеження? економія навантаження на базу даних?
2) відбивання спроб звантажити базу (любителі були, хоча словники доступні в pdf)
4) щоб не перевантажувати сторінку результатів (бо коли видає 25 сторінок значить щось не так з пошуком)
взагалі, було б добре, якби крім пошуку, словники можна було переглядати у вигляді списку слів, відсортованого за буквами/складами
Чесно пишучи, мене б самого більше цікавила сама база даних, аніж якийсь там pdf.
До того ж, словників усе дедалі більше, тобто й результатів відповідно. Я нічого поганого не бачу, в тому, що користувач шукає одне слово, яке по тридцять раз трапляється в одному словнику і шукати його по всім одночасно. Звісно, цим не потрібно зловживати, але інколи потрібно. І, звісно, обмеження повинні бути, але не такі маленькі. Я не думаю, що навантаження буде менше, якщо я по кожному словнику буду шукати окремо. Власне, вам видніше, чи сервер це витримає, але це єдине, що мене дратує.
а що саме з бази даних цікавить (можна це перенести в приват)? бо я якраз не проти піти на пенсію і віддати це все господарство комусь молодшому з купою енергії, що зробить з проекту нарешті гарну цяцю
Щодо бази — це її структура, словом, не Вам же це пояснювати.
\d src Table "public.src" Column | Type | Modifiers --------------+-----------------------------+------------------------------------------------------------ word_id | integer | not null default nextval('src_word_id_seq'::regclass) word_str | character varying | state | integer | default 0 word_str_ru | character varying | word_str_uk | character varying | word_str_rub | character varying | ts_uk | tsvector | ts_ru | tsvector | last_edit_tm | timestamp without time zone | Indexes: "src_pkey" PRIMARY KEY, btree (word_id) CLUSTER "src_state" btree (state) "ts_ru_idx" gist (ts_ru) "ts_uk_idx" gist (ts_uk)
Ось цього в тому pdf і бракує.
