Коллеги, приветствую!

В MSSQL (именно с ней работаем) есть оператор like.

Не знаете готовой реализации такого оператора только на delphi?

Например, в MSSQL пишу
  [Data] like 'wwr%dsfd%sdfs%sdfsf'
Хочу иметь в Delphi функцию
  Like(Data, 'wwr%dsfd%sdfs%sdfsf'), где результат типа boolean.

регулярки же

Оператор like работает как регулярки? Первый раз слышу.

> Оператор like работает как регулярки?


Ему трудно работать иначе

> Игорь Шевченко ©   (19.12.16 14:17) [3]
> > Оператор like работает как регулярки?
> Ему трудно работать иначе


Я неточно выразился. Сейчас поправлюсь.

Функционал регулярок существенно шире, чем оператора like (как минимум в MSSQL2000). Вот кусок справки из MSSQL2000:

% - Any string of zero or more characters.
_ - (underscore) Any single character.
[ ] - Any single character within the specified range.
[^] - Any single character not within the specified range.

Видно, что возможности like на порядок ниже, чем у регулярок (даже в диалоге Find Text в Delphi возможности поиска по регулярным выражениям существенно шире).

Отсюда очевидный (для меня) вывод, что в MSSQL оператор like реализован не на основе регулярок, а сделан специально под функционал, который и привел выше как выдержку из справки. Почему я так думаю? Потому, что реализовать описанный функционал и только его существенно проще в части производительности алгоритма, чем использовать мощные регулярки (используя из них 10% функционала), а, сам понимаешь, like должен работать быстро (это очень важное требование).

Если я не прав, и для реализации like используется рег. выр., то почему оператор like такой убогий по сравнению с рег. выр.? Может у тебя в Oracle like крут, как регулярки. Но я работаю на MSSQL и его like мне хватает для моих задач. Сейчас же хочу некоторую фильтрацию делать на клиенте (вернее в промежуточном сервисе) на Delphi.

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

> Поэтому мой вопрос был о том, видел ли кто-то уже реализованный
> на Delphi оператор like без лишних возможностей, которые
> непосредственно в like не используются.


Добавлю.
Написать like я могу. Но не уверен, что сделаю это хорошо - нужна скорость работы. А это можно только на асме сделать хорошо. А асм я не знаю.
Есть надежда, что кто-то умный уже написал подобный алгоритм, просто я о нем не знаю.

> Функционал регулярок существенно шире, чем оператора like


Скажем так, принцип сопоставления с образцом в регулярных выражениях и в операторе like одинаков. Отсюда следует, что написать регулярное выражение с использованием синтаксиса регулярных выражений, соответствующее поведению оператора like не сложно.

> iop ©   (19.12.16 15:12) [7]
> то почему оператор like такой убогий по сравнению с рег.
>  выр.?
> https://cdn.meme.am/cache/instances/folder559/500x/74067559.
> jpg


Ну и что это значит?

то что для программиста ты слишком увлечен философствованиями. возьми наследуйся от тобджект, инкапсулируй регулярки и вынеси наружу один матч который сделай таким же убогим как лайк.

> iop ©   (19.12.16 15:52) [9]
> то что для программиста ты слишком увлечен философствованиями.
>  возьми наследуйся от тобджект, инкапсулируй регулярки и
> вынеси наружу один матч который сделай таким же убогим как
> лайк.

Про философствование точно подмечено.
Но именно это философствование помогает мне 23 года поддерживать мои проекты (в сумме ляма на 2 строк). Ну это я так, похвалился немного, больше не буду)))

Чес в начале нулевых, когда надо было много писать (не особо философствуя) у меня прошел. Процентов на 50 у меня теперь рефактор идет того, что нефилософствуя наплодил раньше. Теперь имею возможность подумать (пофилософствовать) и сделать сразу хорошо. Разве это плохо?

Мое программистское чутье говорит мне о том, что даже хорошая реализация регулярок будет медленнее работать, чем реализация like, написанная чисто под like.

Можно, конечно, попробовать. Ты вот какими регулярками в дельфи пользуется? У меня в Дельфи2007 штатной регулярки нет. Надо где-то брать.

> Мое программистское чутье говорит мне о том, что даже хорошая
> реализация регулярок будет медленнее работать, чем реализация
> like, написанная чисто под like.


Мое программистское чутье говорит, что скорость очень хорошо определяется тестовыми примерами, а узкие места - профилировщиком.

> Мое программистское чутье говорит, что скорость очень хорошо
> определяется тестовыми примерами, а узкие места - профилировщиком.


Игорь, и тебя тоже спрошу - ты какой библиотекой регулярных выражений пользуешься? (в моем дельфи 2007 штатной подобной библиотеки нет).

в моем дельфи 2007 штатной подобной библиотеки нет

беда беда.....

есть паскалевский модуль регулярок.
так же везде есть com VBScript.RegExp

> Игорь, и тебя тоже спрошу - ты какой библиотекой регулярных
> выражений пользуешься?


Я никакой не пользуюсь - мне не надо

Но именно это философствование помогает мне 23 года поддерживать мои проекты (в сумме ляма на 2 строк). Ну это я так, похвалился немного, больше не буду)))


по хорошему тебя надо просто уволить. вместе с твоими лямами.
в 23 это еще бывает неочевидно.

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

зачем ты такой нужен?

> Игорь Шевченко ©   (19.12.16 16:52) [14]

Предельно лаконичный ответ, поддерживаю!

Удалено модератором

Удалено модератором

Удалено модератором

Удалено модератором

Сожалею, что дискуссия пошла не туда, но тесты провел.

1. Отсюда http://regexpstudio.com/TRegExpr/TRegExpr.html взял TRegExpr.
2. Написал свою аналогичную функцию: упрощенный like, реализовал только % (другие вайлдкарды мне не нужны).
3. Провел 5млн поисков по выражению '60/1.*/100.*/1' по строке '60/11/1001/1'.
Мой код в ~3 раза быстрее (1.4 сек против 3.9 сек).
4. Отсюда делаю вывод: если мне нужен реально быстрый like, то нужно его писать самому (раз уж нет готовой реализации), а не пользоваться рег. выражениями. Еще лучше, если сделать его на асме, уверен, что будет еще быстрее.

Полагаю, что тема исчерпана.

круто, чо....

жаль только что мы не узнаем время, требуемое на вытягивание с mssql на клиента этих пяти мультов значений для клиентского лайка.

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

как никак почти сутки потрачены.

> iop ©   (19.12.16 20:05) [22]
> жаль только что мы не узнаем время, требуемое на вытягивание
> с mssql на клиента этих пяти мультов значений для клиентского
> лайка.


А что узнавать, время - 0.
Ибо данные уже находятся на моем же сервисе, в который заталкиваются данные при изменении в БД. Т.е. своего рода репликация... колхозная.
Конечно, есть потери времени при изменении БД. Но для моего случая они приемлемы, ибо специфика такова, что добавление данных не слишком массированное. Также возможна рассинхронизация, т.к. распределенной транзакции нет. Но в моем случае вероятность данной опасности стремится к нулю.

ЗЫ Приятно был удивлен скоростью работы TRegExpr. Изначально полагал, что разница будет существеннее.

не надо нас дурить, мы не отдыхающие
данные твои на сервере и им потребовался клиентский лайк.

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

значит данные на mssql.
а это значит, что чтобы отрапортовать шефу об экономии в 2.5 секунды надо сначала положить офисную сеть на время фетча с сервера этих пяти мультов записей.

> iop ©   (19.12.16 20:22) [24]
> данные твои на сервере и им потребовался клиентский лайк.


Серверов несколько.
Один - MSSQL.
Второй - сервис (мой), в котором и нужен like.


> а это значит, что чтобы отрапортовать шефу об экономии в
> 2.5 секунды


Я, пожалуй, обойдусь без репорта: просто перенесу информацию из одной извилины мозга в другую. Вот и весь репорт.

ой как жалко......
так напрягался и упирался лишь бы не осваивать синтаксис полноценных регулярок,
даже выиграл 2.5 секунды на пяти мультах значений,
и даже уже понял, что этого никто не заметит,
так как эти пять мультов еще выкачать надо......

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

> iop ©   (19.12.16 20:37) [26]
> даже выиграл 2.5 секунды на пяти мультах значений,
> и даже уже понял, что этого никто не заметит,
> так как эти пять мультов еще выкачать надо......


Коллега, почему вы невнимательно читаете?
Данные выкачены (отреплицированы) в моем сервисе (в его памяти).
И расчеты будут вестись в рамках этого сервиса. Без обращения к БД.
Like'ов будет много. Очень. Поэтому 2.5 секунды большой выигрыш.

Данные выкачены (отреплицированы) в моем сервисе (в его памяти).

я читаю внимательно.

и пишу тоже внимательно.

и написал я про то,
что для того, чтобы заметить твои усилия по экономии
двух с половиной секунд
надо выкачать по сети с сервера пять миллионов записей.

и да, я внимательно прочитал, что ты их уже когда-то выкачал.
возможно не с одного сервера и не за один раз.

и я внимательно после этого пишу и внимательно замечаю,
что реальный выигрыш - он мизерный.

хотя синтетический выигрыш и составляет 2.5 секнды на пять мультов записей.

только эти пять мультов - они размазаны по времени.
может на сутки может на неделю.

и на этих реальных сутках (или неделе) ты и выиграл те самые две с половиной секунды.

.... и это я еще не упомянул,
что после клиентского лайка
лайкнутые данные полетят опять
по сети
на сервера.

> iop ©   (19.12.16 20:54) [28]


0. Время выкачки 5 мультов данных не обсуждаем. Ибо данные вообще могут получаться разными путями (хоть выкачка из БД ночью в файл с последующим использованием файла сервисом).

1. Представь себе, что есть информационная система (специально не говорю про БД, чтобы не было ошибочного мнения, что речь идет про SQL-сервер), в которой есть один большой массив:


Большой, это какой? Ну лям, может два. Пять лямов в моих тестах - это был запас прочности.
Поле key - это что-то типа строки, написанной выше.
Важно! Всего вариантов key не очень много (тысяч 20 максимум).
Про количество вариантов key я говорю, чтобы было понятно, что сервис на клиенте будет возвращать не так много данных (существенно меньше, чем те 5 лямов).

2. Мне нужно получать некую агрегированную информацию по массиву А.
Для этого моему сервису выдается задание: посчитай мне суммы value, у которых key удовлетворяет следующим маскам (т.е. передается набор масок) и верни мне массив этих сумм. Для нахождения суммы мне нужно будет в том или ином виде просматривать А и делать like для key. Фактов вызова like будет много.

3. В итоге время выполнения задания разбивается на две составляющие:
  а. Время like.
  б. Время суммирования value.
Поэтому, если я смогу сэкономить на пункте а, то это уже неплохо.
В общем времени работы сервиса - это будет немалая величина. Особенно при большом входном массиве key.

. Время выкачки 5 мультов данных не обсуждаем.

жалко.
как же без знания этого времени нам проникнуться почтением к двум с половиной секндам экономии?

Мне нужно получать некую агрегированную информацию по массиву А.

ой, а разве на sql сервере, в первоисточнике так сказать,
нельзя выполнить запрос с непрокачанным на две секунды sql-лайком?

Поэтому, если я смогу сэкономить на пункте а, то это уже неплохо.
"уже" неплохо будет, если экономия будет заметна.
а она незаметна.
так как первичные данные - они на сервере, а лайк он - на клиенте.

но мы про время фетча не хотим говорить, а как бы считаем что данные сразу у нас.

ой, я кажется понял!

тебе не только регулярки излишни потому что медленны, и нужны свои, умеющие только один метасимвол обрабатывать!

не только лишь они!!!!

тебе не нужен настоящий sql сервер!

нужен свой.
умеющий только :
2. Мне нужно получать некую агрегированную информацию по массиву А.

точно!.
это еще пара секунд экономии.

правда года три упорного труда на написание .....
но это же фишня.
это уже само по себе хорошо!

> iop ©   (19.12.16 21:18) [32]

Коллега, а вам вообще знакома архитектура систем типа google?
Или любой другой, где используется горизонтальное масштабирование?

да откуда!
у меня же регексп в юзесах издревле сидел.

Или любой другой, где используется горизонтальное масштабирование?
вот любой другой - да. знаком.
свой.
с масштабированием, асинхронностью, гетерогенностью и кроссплтформенностью во всех трех слоях и прочими поэтессами.

> iop ©   (19.12.16 21:30) [34]
> вот любой другой - да. знаком.
> свой.
> с масштабированием, асинхронностью, гетерогенностью и кроссплтформенностью
> во всех трех слоях и прочими поэтессами.


Вот и вы, коллега, хвастаться начали. Но будем считать, что я этого не заметил.
Завязываем с этим разговором, который ничего полезного никому не принесет.

кто хвастается?
меня спросили имею ли я понятие о высоких материях.
ответил что имею.

который ничего полезного никому не принесет.

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

есть первичные данные.
хочется отчетов и прочей аналитики - юзай первичные данные.

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

какими бы распределенными они ни были.

> iop ©   (19.12.16 21:44) [37]

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

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

Так какую сущность мы воспринимаем по-разному? Тут лучше всего подойдет первое предложение Анны Карениной Л.Н. Толстого: Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему. Иносказательно я хочу пояснить мысль, что у каждого из нас своя система, которая эксплуатируется и развивается не первый год, есть практика, есть подходы, есть много кода, который написан, есть свои известные архитектурные косяки (или Вы святой и косяков нет?!). У каждого из нас есть представления, как правильно строить такие системы!

И, вот потому как у каждого свое видение архитектуры, пользы не будет.

Мы же не архитектуру исходно моей системы обсуждали, верно?
Вопрос был простой - есть ли реализации like'а.

чо тут понимать-то?

ты вынул данные из их нативного хранилища и засунул в свой сервис.
и по началу все было хорошо.
но вдруг однажды понадобилось ТАМ обрабатывать клиентский массив но как бы по лайку.
и ты начал рисовать свой как бы скл-сервер со своим как бы лайком.

хотя нативный лайк и все остальное многобразие средств tsql никуда не делось.
просто кто-то решил, что данные удобнее хранить и обрабатывать в своих сервисах, а не там где это лучше и проще.

вот и весь сказ.

> iop ©   (19.12.16 22:06) [39]


Хороший тезис. Продолжаем)

Как вы в своей масштоасинхронногетерогеннокроссплтформенной системе решаете следующую задачу: построение отчетов?

Вот есть, например, отчет, который затрагивает таблицу, в которую ведутся постоянные (раз в секунду, например) добавления. Отчет на sql строится долго - несколько минут.

Вот как вы избегаете deadlock'ов?

> Вот есть, например, отчет, который затрагивает таблицу,
> в которую ведутся постоянные (раз в секунду, например) добавления.
>  Отчет на sql строится долго - несколько минут.
>
> Вот как вы избегаете deadlock'ов?


Используя соответствующие уровни изоляции транзакций, вроде, иначе трудно.

> Игорь Шевченко ©   (19.12.16 22:33) [41]
>
> Используя соответствующие уровни изоляции транзакций, вроде,
>  иначе трудно.


Игорь, неужели у вас не бывает deadlock'ов?
Ну вот представь, что нужен серьезный отчет - из 10 таблиц да еще и за год.
А при этом в таблицы добавляются данные, изменяются данные, удаляются данные.

Неужели нет проблем?

ЗЫ Знаю, что у тебя Оракл. Петр Абрамов мне рассказывал, что Оракл творит чудеса, будучи версионником. Но поверить сложно...

> Неужели нет проблем?


А с чего бы им появиться ?
Тебя не удивляет же тот факт, что штатными средствами делается резерная работоспособная копия базы данных, в которую во время копирования могут также вноситься изменения.
Про изоляцию транзакций в MS SQL тут все вроде написано
https://msdn.microsoft.com/ru-ru/library/ms173763.aspx

> Отчет на sql строится долго - несколько минут.

Это не долго. Проходил практику, там бывало отчёты по 15 минут думали (запросы сами).
Запихнуть весь этот запрос в штатный профилировщик и создать в БД индексы, которые тот посоветует?

An a Student   (20.12.16 00:24) [44]

"Вы, сударь, ерунду говорите. И хуже всего то, что говорите безапеляционно и уверенно"

> http://regexpstudio.com/TRegExpr/TRegExpr.html
тоже раньше пользовался, пока не наткнулся на какое то ограничение (там в модуле посмотри 2004го года вроде последнее обновление) пришлось срочно переделывать на http://www.regular-expressions.info/pcre.html (перловский синтаксис)

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

> sniknik ©   (20.12.16 13:34) [46]


1. Ты только не подумай, что на основе одного примера я делаю выводы, что все, что написано другими - плохо, а все мое - хорошо.
Вот сам пример (понятно, что утрированный):


У меня на Дельфи2007 он выполняется 2808 сек. Причина в StringReplace (жуткий алгоритм).
Мой аналогичный алгоритм делает это за 0.2 сек.

Это я к тому, что генофонд от производителя не всегда безупречен.
И в определенных случаях, возможно, что самописное решение будет лучше стандартного.
Так... немного философии.

2. Теперь по сути. Все обсуждаемое еще не написано полностью, но все требуемые компоненты (сервисы, сервер на им. каналах,  пр.) есть из других проектов. Пока думаю над горизонтальным масштабированием: считать некоторые отчеты не в БД, а рядом. Хочу пилота сделать и представить остальному коллективу.
Но коллега iop (с) поселил во мне сомнения в правильности того, что я хочу сделать. Возможно, он прав и надо убиться об стену, но считать все в БД. Буду думать.

3. Насчет ADO. Спасибо, посмотрю.

4. Индексы есть. По сути вариантов key не так много (несколько тысяч). Все различные варианты key+индексы соответствующих строк в А по сути и есть индекс.
С учетом малости вариантов key согласен с коллегой iop (c), что можно воспользоваться TRegExpr, а не писать свой like.

> Это я к тому, что генофонд от производителя не всегда безупречен.


Всякий овощ приносит пользу будучи употреблен надлежащим образом в надлежащее время.

Ты привел неудачный пример для иллюстрации. Можно и содержимое большого файла обрабатывать, прочитав его в TMemo, и так тоже делают, но этот вовсе не повод для критики TMemo.

> Игорь Шевченко ©   (21.12.16 14:31) [48]
> Ты привел неудачный пример для иллюстрации.


Ну почему же?

Вот нужно тебе в большом тексте заменить одно на другое. Берешь StringReplace (а с чего бы взять другую функцию? функция есть, она описана, не сказано, что не подсовывать большие строки). И получаешь результат в 2808 секунд.

Вот ты бы в подобной ситуации (когда надо заменить в большой стоке одно на другое) взял бы другой овощ (функцию)? Какую? Как бы ты, опытный разработчик, понял, что использовать StringReplace не надо ибо она медленная?

Пример, кстати жизненный. В доке к MSSQL сказано, что sp_exec кеширует план запроса, если все объекты fully qualified, т.е. имеют префикс [DataBaseName].[dbo] перед таблицами, процедурами и вьюхами. Я собрал батч, где место для [DataBaseName].[dbo] помечено маркером, вызвал замену маркера на [DataBaseName].[dbo] и сижу жду... Честно говоря, я когда наконец понял, почему у меня стало в порядок работать медленнее, был поражен неоптимальностью алгоритма в StringReplace...

> Мой аналогичный алгоритм делает это за 0.2 сек.
сравни вот с этим http://www.loginovprojects.ru/index.php?page=faststringreplace
у меня он показал 16 милисекунды, хотя это на разных машинах ничего не значит, StringReplace проверять не стал (подождал с минуту и прервал)

время засекал так

> Вот нужно тебе в большом тексте заменить одно на другое


а) Мне крайне редко нужно менять "в большом тексте одно на другое"
б) Еще в 1988 году я написал себе функцию замены текста (на С, разумеется), которая приемлемо по скорости работала и если мне таки потребуется поменять в "большом" тексте, я буду использовать приемлемый алгоритм.

> sniknik ©   (21.12.16 17:24) [50]
> > Мой аналогичный алгоритм делает это за 0.2 сек.
> сравни вот с этим http://www.loginovprojects.ru/index.php?
> page=faststringreplace

Спасибо. Быстрее в 4 раза. Возьму его. Пусть будет. К тому же мой не работает в режиме IngnoreCase (не нужно было и не написал).

Тимохов Дима ©   (19.12.16 22:13) [40]

   Честно говоря не совсем понятно с чем связаны deadlock у вас, но это не причина, писать какой-то свой сервер подобие SQL, в крайнем случае можно использовать  2 SQL сервера для разных задач.
  Рассмотрите повышение производительности другими путями, пересмотрите код (к стати в некоторых отчетах можно использовать "грязное чтение"), возможно серверу можно добавить просто ОЗУ либо более быстрые диски поставить.
Не забывайте о том что в итоге такой проект выйдет дороже чем апгрейд сервера. Сделать пилот это одно, а потом провести его тестирование, вылавливать баги и заниматься поддержкой - другое.

> Игорь Шевченко ©   (19.12.16 22:33) [41]
>
> > Вот есть, например, отчет, который затрагивает таблицу,
>  
> > в которую ведутся постоянные (раз в секунду, например)
> добавления.
> >  Отчет на sql строится долго - несколько минут.
> >
> > Вот как вы избегаете deadlock'ов?
>
>
> Используя соответствующие уровни изоляции транзакций, вроде,
>  иначе трудно.

Исчерпывающий ответ!
Просто это сообщение... возникает в процессе развития БД, от его очень трудно избавиться, не переписывая логику. А так чтение ни при чем.

> трудно избавиться, не переписывая логику


Это придется сделать рано или поздно. т.к. частые deadlock это не нормально при любой нагрузке.
А какая версия MS SQL ?