Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Бази даних → Збереження результатів виконанння sql запиту
Сторінки Попередня 1 2 3 4 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
Шкода. А в мене ще стільки ідей було...
гуглю зараз на рахунок цього, можливо англійською вдасться щось знайти, якщо щось відшукаю обов'язково Вам відпишу.
Здається, маю трохи кращу ідею за стоворення нової таблиці(до неї треба ж буде додавати нові записи і слова мені не тільки на 5 букв потрібні), а що, якщо я додам нову колонку, в яку буду вписувати довжину слова і індекс по ній замутити?
ось, що пишуть на офіційному сайті https://www.sqlite.org/partialindex.html
The WHERE clause may not contains subqueries, references to other tables, functions, or bound parameters.
The LIKE, GLOB, MATCH, and REGEXP operators in SQLite are implemented as functions by the same name. Since functions are prohibited in the WHERE clause of a CREATE INDEX statement, so too are the LIKE, GLOB, MATCH, and REGEXP operators.
Only rows of the table for which the WHERE clause evaluates to true are included in the index
а що, якщо я додам нову колонку, в яку буду вписувати довжину слова і індекс по ній замутити?
по моєму таке рішення було очевидно з самого початку.
1-ша версія
SELECT column FROM table where LENGTH(column)=5 // ну мені там треба буде вибрати рандомно 1 запис тому
2-га версія
SELECT column FROM table where LENGTH(column)=5 ORDER BY RANDOM() LIMIT 1
При використанні саме функції для певного поля, швидше за все, не використовується його індекс.
Судячи зі всього (якщо ви збираєтесь створювати додаткове поле, де буде всього лише 5 символів), то вам потрібно саме 5 конкретних символів. Якщо це 5 перших символів, то є можливість використовувати індекси без необхідності створювати додатково інше поле (звичайно ж, якщо тільки поле пошуку не надто велике).
Спробуйте таке:
SELECT column FROM table where column like '_____%'По-ідеї (я таке в SQLite не перевіряв) це вибиратиме саме 5 перших символів (символ підкреслення в SQL для оператора like символізує один будь-який символ).
Для використання індексів, тут головне правило - не використовуйте функції, а при використанні оператора like символ процента не повинен іти попереду виразу (лише позаду).
Regen написав:1-ша версія
SELECT column FROM table where LENGTH(column)=5 // ну мені там треба буде вибрати рандомно 1 запис тому
2-га версія
SELECT column FROM table where LENGTH(column)=5 ORDER BY RANDOM() LIMIT 1При використанні саме функції для певного поля, швидше за все, не використовується його індекс.
Судячи зі всього (якщо ви збираєтесь створювати додаткове поле, де буде всього лише 5 символів), то вам потрібно саме 5 конкретних символів. Якщо це 5 перших символів, то є можливість використовувати індекси без необхідності створювати додатково інше поле (звичайно ж, якщо тільки поле пошуку не надто велике).Спробуйте таке:
SELECT column FROM table where column like '_____%'По-ідеї (я таке в SQLite не перевіряв) це вибиратиме саме 5 перших символів (символ підкреслення в SQL для оператора like символізує один будь-який символ).
Для використання індексів, тут головне правило - не використовуйте функції, а при використанні оператора like символ процента не повинен іти попереду виразу (лише позаду).
Ви не зрозуміли, мені потрібно вибрати слова довжиною у 5 символів, а не 5 перших символів тому я уже додав новий стовпець, в якому вписав довжину кожного слова і здійснив індексацію по ньому, щоправда так швидко, як я сподівався запит не працює
максимум 807 проти 1200
мінімум 461 проти 780 (мс)
Ви не зрозуміли, мені потрібно вибрати слова довжиною у 5 символів, а не 5 перших символів тому я уже додав новий стовпець, в якому вписав довжину кожного слова і здійснив індексацію по ньому, щоправда так швидко, як я сподівався запит не працює
максимум 807 проти 1200
мінімум 461 проти 780 (мс)
Ні, схоже, що це ви не зрозуміли - я написав загальний приклад, який годиться не лише для вашого випадку. А якщо його застосовувати до вашого випадку, то треба лише прибрати символ процента.
І потім, якщо ви індексуєте свій стовпець, то ви ж робите якийсь пошук, чи ні? Чи просто вибираєте непусті значення? До речі, ви не забули прибрати функцію підрахунку символів в селекті? (Бо щось занадто повільно вибирає)
До речі, а якщо
CREATE VIEW lengthof5 AS
SELECT column
FROM table
WHERE LENGTH(column)=5;- вид може кешуватися, що дасть потрібну швидкість без негативних сторін (хоча сильно не певен, треба перевіряти).
До речі, а якщо
CREATE VIEW lengthof5 AS SELECT column FROM table WHERE LENGTH(column)=5;- вид може кешуватися, що дасть потрібну швидкість без негативних сторін (хоча сильно не певен, треба перевіряти).
Кажу ж вам - оце LENGTH(column)=5 виключає можливість використовувати індекси, і, до речі, кешуються якраз запити, але припарені (prepare)
UPD:
Хоча зараз перевірив через MySQL то використовуються індекси і з LENGTH(column)=5.
Хм, цікаво, чого це я так запам'ятав
koala написав:До речі, а якщо
CREATE VIEW lengthof5 AS SELECT column FROM table WHERE LENGTH(column)=5;- вид може кешуватися, що дасть потрібну швидкість без негативних сторін (хоча сильно не певен, треба перевіряти).
Кажу ж вам - оце LENGTH(column)=5 виключає можливість використовувати індекси, і, до речі, кешуються якраз запити, але припарені (prepare)
UPD:
Хоча зараз перевірив через MySQL то використовуються індекси і з LENGTH(column)=5.
Хм, цікаво, чого це я так запам'ятав
ем, ну дивіться, я виконав такі дії:
ALTER TABLE table ADD len;
UPDATE table SET len = LENGTH(column);
CREATE INDEX Ilen ON table(len);і тепер використовую такий запит
SELECT column FROM table WHERE len = 5;До речі, а якщо
CREATE VIEW lengthof5 AS SELECT column FROM table WHERE LENGTH(column)=5;- вид може кешуватися, що дасть потрібну швидкість без негативних сторін (хоча сильно не певен, треба перевіряти).
дякую, зараз спробую, щоправда саме кешування мені не потрібне
хоча, я, здається, доганяю, чому при вибірці 5 символьних полів індекс не дає бажаного результату: тут вибірковість велика (записів 40К, а записів, які містять 5 символів 4К), а індекси добре працюють при малій вибірковості
хоча, я, здається, доганяю, чому при вибірці 5 символьних полів індекс не дає бажаного результату: тут вибірковість велика (записів 40К, а записів, які містять 5 символів 4К), а індекси добре працюють при малій вибірковості
Жесть, ви заганяєте 4 тисячі записів в пам'ять і хочете швидкої роботи, тим більше, на телефоні? Ні, тут звичайно ж ніякі індекси не допоможуть. Це по-перше.
По-друге, сподіваюсь, ви ж не виводите всі ці 4К записів на сторінку? Мабуть же робите якісь маніпуляції з ними, наприклад, вибірку вже самою PHP. Так?
Пане ktretyak, у вас дивні уявлення про обсяги інформації. Ви про алгоритми логарифмічної складності взагалі чули? От індекси їх і використовують. Системи на 1МГц-процесорах цілком пристойно працювали з тисячами запитів, уявіть собі.
Пане ktretyak, у вас дивні уявлення про обсяги інформації. Ви про алгоритми логарифмічної складності взагалі чули? От індекси їх і використовують. Системи на 1МГц-процесорах цілком пристойно працювали з тисячами запитів, уявіть собі.
Ні не чув, про "алгоритми логарифмічної складності", але одна справа робити вибірку з тисячі рядків, а інша справа, як я і наголошував, заганяти в пам'ять вибірку в 4 тисячі.
Навіть про бінарний пошук не чули? Повірте - індексованому масиву на 40 тисяч елементів достатньо 16 перевірок, щоб знайти потрібне значення.
Навіть про бінарний пошук не чули? Повірте - індексованому масиву на 40 тисяч елементів достатньо 16 перевірок, щоб знайти потрібне значення.
Добре, що ви знаєте ці поняття про алгоритми пошуку, але очевидно, ви і в другий раз не почули на чому я наголошую. Мабуть тоді, в цьому плані, ви ще не дуже досвідчені.
Звичайно ж я повністю погоджуюсь з вами, що таблиця з 40 тисячами записів для вибірки по індексованим полям це досить простеньке завдання. Але загон в пам'ять навіть 4 тисяч рядків, особливо для пам'яті телефона, це далеко не таке ж саме просте завдання.
4 тисячі рядків по 100 байт (наприклад) - це 400 кілобайт. Ви вважаєте це страшним об'ємом? Навіть на телефоні...
Ні, розумію, в часи 1МГц/1МБ це було важкувато, але зараз... Хоча, звісно, пане Regen, ви б зізналися - нащо вам ці рядки? Що із ними далі робите?
4 тисячі рядків по 100 байт (наприклад) - це 400 кілобайт. Ви вважаєте це страшним об'ємом? Навіть на телефоні...
Ні, розумію, в часи 1МГц/1МБ це було важкувато, але зараз... Хоча, звісно, пане Regen, ви б зізналися - нащо вам ці рядки? Що із ними далі робите?
потрібно рандомно вибрати 1 запис, довжина якого 5 символів(ну тобто поля)
Regen написав:хоча, я, здається, доганяю, чому при вибірці 5 символьних полів індекс не дає бажаного результату: тут вибірковість велика (записів 40К, а записів, які містять 5 символів 4К), а індекси добре працюють при малій вибірковості
Жесть, ви заганяєте 4 тисячі записів в пам'ять і хочете швидкої роботи, тим більше, на телефоні? Ні, тут звичайно ж ніякі індекси не допоможуть. Це по-перше.
По-друге, сподіваюсь, ви ж не виводите всі ці 4К записів на сторінку? Мабуть же робите якісь маніпуляції з ними, наприклад, вибірку вже самою PHP. Так?
рандомно вибираю 1, ні не php, а java, вірніше Android
Навіть про бінарний пошук не чули? Повірте - індексованому масиву на 40 тисяч елементів достатньо 16 перевірок, щоб знайти потрібне значення.
а це тру, так само як і про алгоритми з логарифмічним часом виконання