Вверх ↑
Этот топик читают: parara, Гость
Разработчик
Ответов: 25466
Рейтинг: 2071
#91: 2007-08-31 21:41:16 ЛС | профиль | цитата
Alexbootch, пробовал, ругается на SELECT, но я пробовал не с одним полем, а с несколькими, через запятую. Попробую по-одному. Оно еще к полям другой таблицы в UPDATE обращаться не хочет.
карма: 19

0
Ответов: 1891
Рейтинг: 110
#92: 2007-08-31 21:50:46 ЛС | профиль | цитата
Должно работать. Например вот этот запрос работает на elements.db:

UPDATE elements SET info = (SELECT info FROM groups WHERE rowid = 4 ), tab = (SELECT name FROM groups WHERE rowid = 4) WHERE rowid = 2


Возможно у тебя где-то ошибка синтаксиса - вот sqlite и ругается на SELECT
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#93: 2007-08-31 21:58:57 ЛС | профиль | цитата
Alexbootch, да-да, возможно и была ошибка. Я проверил, работает. Но всеже, можно ли сохранить строку не создавая дополнительной таблицы (вот для чего я спрашивал про переменные)?
карма: 19

0
Ответов: 1891
Рейтинг: 110
#94: 2007-08-31 22:03:40 ЛС | профиль | цитата
nesco, писал(а):
Но всеже, можно ли сохранить строку не создавая дополнительной таблицы (вот для чего я спрашивал про переменные)?


Модификацию строки произвести взяв данные из другой строки (строк) этой же таблицы? Или как?
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#95: 2007-08-31 22:09:04 ЛС | профиль | цитата
Alexbootch, для перемещения строк необходимо чтобы одна строка была в памяти, другую в это время размножаем в соседней строке (в зависимости от направления) и затем сохраненную вписываем в нужное место. Для сохранения нужной строки я использовал временную таблицу, но это медленные операции (создание, модификация, очистка, сжатие)
карма: 19

0
Ответов: 1891
Рейтинг: 110
#96: 2007-08-31 22:39:51 ЛС | профиль | цитата
nesco, писал(а):
Для сохранения нужной строки я использовал временную таблицу, но это медленные операции (создание, модификация, очистка, сжатие)


Create Table Channels_temp...



это не есть временная таблица, т.к. временная таблица создается так:

CREATE TEMPORARY TABLE.......


Кстати временную таблицу можно и не удалять, т.к. она сама удалится при закрытии базы.

Как вариант можно попробовать создать копию базы предварительно переименовав саму базу и нужную таблицу, а затем подключить обе базы.
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#97: 2007-08-31 23:04:56 ЛС | профиль | цитата
Alexbootch, после создания временной таблицы, сжатие (VACUUM) проводить не обязательно, я правильно понял? Сейчас попробую.
Alexbootch писал(а):
переименовав саму базу и нужную таблицу

А каким запросом переименовывается таблица?

карма: 19

0
Ответов: 1891
Рейтинг: 110
#98: 2007-08-31 23:53:27 ЛС | профиль | цитата
nesco, писал(а):
Alexbootch, после создания временной таблицы, сжатие (VACUUM) проводить не обязательно, я правильно понял?


Да, правильно, т.к. временная таблица создается не в базе, а в памяти

nesco, писал(а):
А каким запросом переименовывается таблица?


ALTER TABLE elements RENAME TO elements1;


[size=-2]------ Добавлено в 23:53
Можно сделат еще так копию базы:

Подключить базу elements.db и далее:

ATTACH DATABASE 'elements1.db' AS elements1db;

CREATE TABLE elements1db.elements1 (id,name,info,tab,pos,hash)

INSERT INTO elements1 SELECT * FROM elements;

карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#99: 2007-09-01 00:54:30 ЛС | профиль | цитата
Alexbootch, спс, бум думать дальше.

карма: 19

0
Администрация
Ответов: 15273
Рейтинг: 1501
#100: 2007-09-01 01:03:06 ЛС | профиль | цитата
nesco писал(а):
Вот, я написал запросы по физическому перемещению строк, обладающие максимальным быстродействием и лишенными недостатков, описанных Dilmой

это не так.
1) Быстродействие: эффективность снижается линейно с увеличением количества столбцов в строке(все еще далеко от идеала, потому что существует вариант, не зависящий от количества строк и столбцов...)
2) Надежность: пока в приложение есть использование rowid в качестве идентификатора строки оно надежным не будет никогда даже в теории
карма: 23
0
Ответов: 1891
Рейтинг: 110
#101: 2007-09-01 01:17:08 ЛС | профиль | цитата
nesco, а сколько записей у тебя в таблице Channels?
карма: 0
%time%
0
Разработчик
Ответов: 25466
Рейтинг: 2071
#102: 2007-09-01 02:12:21 ЛС | профиль | цитата
Alexbootch, да расчитывал не более чем на 20, хотя фактическго предела нет, ну уж точно не тысячи.

[size=-2]------ Добавлено в 02:12
Dilma писал(а):
Быстродействие: эффективность снижается линейно с увеличением количества столбцов в строке

Снижается, я не спорю, но снижается в любой таблице и с любыми запросами.
Dilma писал(а):
Надежность: пока в приложение есть использование rowid в качестве идентификатора строки оно надежным не будет никогда даже в теории

Ссылку на источник, где описано неэффективность применения rowid, иначе -- это голословное утверждение.
Dilma писал(а):
(все еще далеко от идеала, потому что существует вариант, не зависящий от количества строк и столбцов...)

Приведенный пример не зависит от количества строк, так как в операциях всегда используется только две строки из N количества существующих. В данном случае я не рассматриваю варианты с количеством столбцов больше определенного разумного количества (ну явно не тысяча штук). И вообще я не беру в расчет вариант изменения индексов потому, что мне нужно физическое смещение строк, а не просто вывод в таблицу. Если внимательно почитать весь топик с начала, до конца, до будет понятно, почему я отказался от применения индексов в пользу rowid.
На этапе разработки я думал о применении индексов, но реализация создания мультиканалов в определенной последовательность наиболее простой оказалась именно в такой реализации.
карма: 19

0
Ответов: 16504
Рейтинг: 1212
#103: 2007-09-01 10:26:33 ЛС | профиль | цитата
nesco, а так не проще?
Запоминаем две строки, которые нужно поменять местами и два раза выполняем:
UPDATE Channels SET Idx=%1, Color="%2", Channel="%3", Port="%4", Baud=%5, Factor=%6, Lines="%7", Status=%8 WHERE rowid=%9
карма: 23
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Администрация
Ответов: 15273
Рейтинг: 1501
#104: 2007-09-01 11:09:08 ЛС | профиль | цитата
nesco писал(а):
Снижается, я не спорю, но снижается в любой таблице и с любыми запросами.

нет

nesco писал(а):
Ссылку на источник, где описано неэффективность применения rowid, иначе -- это голословное утверждение.

поправка: про эфекктивность или неэффективность rowid никто не говорил

nesco писал(а):
Если внимательно почитать весь топик с начала, до конца, до будет понятно, почему я отказался от применения индексов в пользу rowid.

не совсем понятно:
nesco писал(а):
у меня в базе нет индексов и никогда не было. Я использую rowid -- абсолютный индекс строки, и не собираюсь заводить еще один столбец для хранения индекса. И вот, кстати, что написано в Helpe по SQLite


nesco писал(а):
потому, что мне нужно физическое смещение строк

может быть стоит открыть базу данных через файловый поток и читать данные напрямую? Быстрее и удобнее однако...
карма: 23
0
Гость
Ответов: 17029
Рейтинг: 0
#105: 2007-09-01 11:53:22 правка | ЛС | профиль | цитата


Редактировалось 2 раз(а), последний 2017-06-14 22:50:12
карма: 0

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)