Оптимизировать перебор записей в таблице

← →
WhiteCat (2007-07-13 13:52) [0]

Здравствуйте.
Подскажите как решать следующую проблему? В таблице на 10000 записей в поле Adress "Россия, Москва, друг детства и т.д." необходимо, допустим, подстроку "Москва" заменить на "Московская область".

Первоначально было такое решение настроить фильтр таблицы на Adress LIKE %Москва% и пройтись по оставшимся записям используя ReplaseString.
Видимо это плохое решение, поскольку возможности Filter ограничены, а использование OnFilterRecord, как мне кажется приведет к еще более медленному выполнению перебора. см.
http://delphimaster.net/view/3-1184266719/

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

← →
clickmaker © (2007-07-13 13:55) [1]

а банальный

update table1
set Adress="Московская область"
where Adress like "%Москва%"

не подойдет?

← →
Сергей М. © (2007-07-13 13:57) [2]

> "Россия, Москва, друг детства и т.д."

Вот эт нихрена себе "адрес" !))

Да при таком адресе и "моск" и "маскалия" может оказаться Москвой, и никакой LIKE при этом не поможет !))

> Пример абстрактный

Абстрактных же и рекомнедаций жди)

А как ты хотел иначе ?)

← →
Ega23 © (2007-07-13 13:57) [3]

> clickmaker © (13.07.07 13:55) [1]

Нахрена так изголяться, когда можно 10000 записей на клиент через TTable вытащить? :)

← →
Сергей М. © (2007-07-13 13:59) [4]

> Ega23 © (13.07.07 13:57) [3]

Нахрена что-то куда-то тащить, если в адресе может оказаться что угодно ?)

Здесь только одно решение - сажать перед гридом негра ти нехай ручками правит))

← →
Ega23 © (2007-07-13 14:01) [5]

> Нахрена что-то куда-то тащить, если в адресе может оказаться
> что угодно ?)

Это шютка юмора была...

← →
clickmaker © (2007-07-13 14:02) [6]

update table1
set Adress=REPLACE(Adress, "Москва", "Московская область")

остальное - негру :)

← →
Anatoly Podgoretsky © (2007-07-13 14:03) [7]

> WhiteCat (13.07.2007 13:52:00) [0]

Используй запросы и функцию Replace

← →
Jan1 © (2007-07-13 14:04) [8]

> Первоначально было такое решение настроить фильтр таблицы
> на Adress LIKE %Москва% и пройтись по оставшимся записям
> используя ReplaseString.

update table1 set Adress=replace(Address, "Москва", "Московская область") where Adress like "%Москва%"

← →
WhiteCat (2007-07-13 14:09) [9]

Ого! Спасибо всем за активную помощь.
К сожалению не знал что в SQL работает Replace. Это решает многое

← →
Anatoly Podgoretsky © (2007-07-13 14:50) [10]

> Ega23 (13.07.2007 13:57:03) [3]

Можно и миллион вытащить

← →
Anatoly Podgoretsky © (2007-07-13 14:52) [11]

> остальное - негру :)

Но именно основное, а не все

← →
Anatoly Podgoretsky © (2007-07-13 14:53) [12]

> К сожалению не знал что в SQL работает Replace.

Я тоже не знал, но у меня есть волшебная книга.

← →
WhiteCat (2007-07-13 15:29) [13]

Ничего не понимаю! Нету такой функции REPLACE!

БД ACCESS, подключение ADO

← →
Anatoly Podgoretsky © (2007-07-13 15:32) [14]

Тогда научись правильно вопрос задавать

← →
WhiteCat (2007-07-13 15:45) [15]

> Тогда научись правильно вопрос задавать

Хорошо! Допустим, что теперь вопрос понятен, могу я рассчитывать на помощь от специалистов?

← →
йцу (2007-07-13 15:50) [16]

http://www.psystatus.ru/

← →
Jan1 (2007-07-13 15:53) [17]

> Ничего не понимаю! Нету такой функции REPLACE!
>
> БД ACCESS, подключение ADO

у меня есть.

← →
sniknik © (2007-07-13 16:22) [18]

> Хорошо! Допустим, что теперь вопрос понятен, могу я рассчитывать на помощь от специалистов?
кто знает теперь,что еще ты скрываеш? ... теперь только помощь приколистов.

Jan1 (13.07.07 15:53) [17]
> у меня есть.
ну так у тебя же аксесс! ;о) (в смысле программа)

← →
WhiteCat (2007-07-13 16:23) [19]

> у меня есть.

Версия ACCESS?
У меня Access XP. Предложенный запрос не сработал. В ключевых словах и в справке функции REPLACE не нашел. Вот все ключевые слова на R:
REAL REFERENCES RESTRICT REVOKE RIGHT ROLLBACK

Все же интересно, если не зацикливаться на функции REPLACE (все же, функция специфическая и не стандартизирована) можно ли решить поставленную проблему?

← →
sniknik © (2007-07-13 16:25) [20]

> Предложенный запрос не сработал.
проверь в аксессе, создав и выполнив там этот запрос

← →
Anatoly Podgoretsky © (2007-07-13 16:25) [21]

В JET такой функции нет.

← →
WhiteCat (2007-07-13 16:29) [22]

> кто знает теперь,что еще ты скрываеш? ... теперь только
> помощь приколистов.

Та ничего я не скрываю, и честно говоря подколка, уважаемого мной, Anatoly Podgoretsky удивляет. Вопрос задан правильно, и Access - это все же из предложенных на форуме баз ближе всего к Microsoft SQL.
Юмор же местных Бачинских и Стилавиных меня не вдохновляет.

← →
Anatoly Podgoretsky © (2007-07-13 16:30) [23]

> WhiteCat (13.07.2007 16:23:19) [19]

Можно, построчная обработка на клиенте.

← →
sniknik © (2007-07-13 16:31) [24]

> можно ли решить поставленную проблему?
при нормально организованной базе это не проблема, даже попытки так сделать в нормальной не возникнет.

нормальная это с адресными справочниками -> страна, город, улица
а в записи только ссылки на них, тогда поиск например города "москва" будет заключаться в индексном, коротком (справочник меньше) поиске id москвы, и выборке связанных с ним из основной, тоже по индексному полю и к тому же числовому по которому все в разы быстрее чем с текстом...

← →
Anatoly Podgoretsky © (2007-07-13 16:32) [25]

> Вопрос задан правильно

Да что ты говоришь.
Внимательно читаем вопрос
"Оптимизировать перебор записей в таблице [D7, MSSQL]"

← →
sniknik © (2007-07-13 16:35) [26]

> и Access - это все же из предложенных на форуме баз ближе всего к Microsoft SQL.
ты не представляешь насколько неправ... это что называется "и близко не лежало". имхо, но FB последних версий к MSSQL ближе чем access.

> Юмор же местных Бачинских и Стилавиных меня не вдохновляет.
не допускай. говори всегда то что есть. а не то что думаешь тоже самое/близкое.

← →
WhiteCat (2007-07-13 16:44) [27]

> а в записи только ссылки на них, тогда поиск например города
> "москва" будет заключаться в индексном, коротком (справочник
> меньше)

Ну просил же не обсуждать реляционную модель. Еще раз говорю, пример я выдумал поскольку долго объяснять смысл реального поля. Ну считайте, что поле не адрес, а просто Comment и надо все нецензурные слова заменить.

И спорить о том что Access это не MSSQL не будем. Я признаю, что неточно указал СУБД. Виноват. Помогите лучше решить поставленную задачу. Ведь должно же быть красивое решение. Да еще уточнение операция не одноразовая, а выполняется довольно часто, поэтому желательно оптимизировать.

← →
WhiteCat (2007-07-13 16:51) [28]

> Можно, построчная обработка на клиенте.

Так первоначально и задумано, а чтоб оптимизировать хотел Filter использовать. Согласитесь построчно 10000 записей обработать солидная задержка. При включенном фильтре работает лучше поскольку остаются только записи, которые уже попадают под требуемый отбор. Но в фильтре нет возможности учесть регистр поскольку "Москва","москва" ,"МОСКВА" разные результаты.

← →
Anatoly Podgoretsky © (2007-07-13 16:58) [29]

> WhiteCat (13.07.2007 16:51:28) [28]

Зачем фильтр?
Запрос с условием, но опять же Акцесс (JET) его не поддерживает.
Стоит подумать об смене СУБД

← →
sniknik © (2007-07-13 17:01) [30]

> Согласитесь построчно 10000 записей обработать солидная задержка.
две,три сек, на среднем компе, это солидно? (впрочем, возможно я переборщил... и займет меньше времени. хотя... если в каждом обрабатываемом текстовом поле чтото типа войны и мира...)

> Но в фильтре нет возможности учесть регистр поскольку "Москва","москва" ,"МОСКВА" разные результаты.
как раз таки в фильтре это будет один результат. но и кроме того тебе предлагали аналог с твоим собственным обработчиком фильтра.

вообще не понимаю, использовать ADOTable (в ссылке) и говорить что чтото оптимизируеш!?!?! нонсенс.

← →
sniknik © (2007-07-13 17:02) [31]

> Запрос с условием, но опять же Акцесс (JET) его не поддерживает.
в смысле? как это не поддерживает?

← →
sniknik © (2007-07-13 17:03) [32]

какого рода условие?

← →
Stanislav © (2007-07-13 17:03) [33]

вместо фильтра в SQL пиши Like "%москва%"

← →
WhiteCat (2007-07-13 17:11) [34]

> вообще не понимаю, использовать ADOTable (в ссылке) и говорить
> что чтото оптимизируеш!?!?! нонсенс.

Хорошо! Пришел на ум красивый пример: Есть таблица с полем комментарий. В таблице большое число записей. Необходимо из всех комментариев удалить указанное нецензурное слово. Как бы вы решали такую задачу?

WhiteCat (13.07.07 17:11) [34]
А что не понятно?

> Пришел на ум красивый пример:
это не пример, отмазка с попыткой получить нужную информацию самому ничего не сказав... а от того, что в исходных данных, что ты не сказал решение может менятся на полную противоположность...

> Как бы вы решали такую задачу?
ну так как я в основном использую MSSQL, и collation у баз делаю case insensetive то очевидно простым запросом update с заменой нужного функцией replace не обращая внимания на регист букв (для insensetive они равнозначны)

помогло?

← →
WhiteCat (2007-07-13 17:30) [39]

> ну так как я в основном использую MSSQL, и collation у баз
> делаю case insensetive то очевидно простым запросом update

Согласитесь, это же не повод всем пользователям Access, InterBase, Paradox, MySQL перейти в срочном порядке на MSSQL.

> Так вроде все уже обсудили. Сказали что нужно сделать...
но еще никто не дал готового кода... т.что жди третий круг. ;о)

← →
WhiteCat (2007-07-13 17:30) [41]

> Так вроде все уже обсудили. Сказали что нужно сделать...

Что нужно сделать??????? Скажите мне.
Поменять СУБД?

Сначала заменить AdoTable на AdoDataSet
Потом написать SQL Select... Where ... like "%москва%"
Потом открыть и вцикле сделать replace
Можно для ускорения использовать LocType:=BathOptimistic

← →
Jan1 (2007-07-13 17:38) [43]

> Что нужно сделать??????? Скажите мне.

единоразовая задача? или это действие в проге? если единовразово, то создай в Аксесе такой запрос [8] и там же его выполни...

> Согласитесь, это же не повод всем пользователям Access, InterBase, Paradox, MySQL перейти в срочном порядке на MSSQL.
моим и не надо, они и так на MSSQL практически половно...

а для других баз могут другие, отличные от этого решения. для того же access 1 запрос на выборку нужных, и цикл по нему с вызовом команды updete в adocommsnd (обязательно параметризированным).
хотя тебе это не пойдет т.к. у тебя почемуто вопреки всем
> ... LIKE "%Москва%"
> ... LIKE "%москва%" дают разные результаты.
т.е. ничего не получится пока не добьешся чтобы было как у всех одинаковые.

> Можно для ускорения использовать LocType:=BathOptimistic
не надо. это не для этого и скорости не добавит.

← →
WhiteCat (2007-07-13 17:42) [46]

to Stanislav
Спасибо, попробую.

sniknik © (13.07.07 17:41) [45]
Почему не добавит?
он же будет в цикле бежать по набору данных и заменять значения, при этом каждая строка будет фиксироваться в базе, а если установить BathOptimistic, то сохранение в базу пройдет в конце цикла 1 раз.

> Почему не добавит?
> он же будет в цикле бежать по набору данных и заменять значения, при этом каждая строка будет фиксироваться в базе, а если установить BathOptimistic,
> то сохранение в базу пройдет в конце цикла 1 раз.
структура рекордсета с BathOptimistic более громозка, там еще добавляется кэширование(под старые значения) - деление значений на новые, старые. а потом при апдейте будет второй цикл по тому же рекордсету с условием если запись изменена то делается тоже самое - "фиксирование в базе". причем не одной командой (в профайлере можно посмотреть). т.е. все тоже самое, только с большим обьемом захваченной под доп.поля памяти, с дополнительными проверками, и "разбитием" одного цикла на 2.
думаешь все эти дополнительные действия сэкономят время? я нет. (хотя, проверь... может я и ошибаюсь)

вообще если делать "ускорение" то я бы сам составил команду апдейта, и выполнял бы ее в асинхронном ADOCommand, тогда бы сэкономилось немного времени, не ожидалось бы завершения команды для перехода на следующую запись основного рекордсета. может быть бы и получилось... (проверить надо (возможно уже в оригинальном так и сделано тогда ;())

Оптимизировать перебор записей в таблице Найти похожие ветки