Ну я проверил. Возможно матчить
1) А всегда,
2) B - только если ранее не встречалась A,
3) C - только если ранее не встречались A или B.
Но только в том случае, если в 2 и 3 можно записать A и B или как статичную строку, или в крайнем случае как множество альтернативных статичных строк.
У меня (пока?) не получилось сконструировать шаблон вроде "Матчить произвольный шаблон B только если ранее не встречался произвольный шаблон А"...
За что люблю серч, так это за большое количество неравнодушных людей, у которых наготове всегда есть много разных непрошеных советов. Ну что поделать, плохо понимаю я беглый британский английский, особенно по телефону.
Вопрос между тем закрыт. Обошелся iMacros'ом для Firefox - чуть больше пятисот номеров пришлось перебрать...
На первый взгляд - самоделка, причем многократно кусками дописанная...
TAFF,
нужно что-то с негативным просмотром назад, типа / (1) | ((?<!1).*?(2)) | ((?<![12]).*?(3)) /sx (s-для того, чтобы переносы строки сопоставлялись точке, х для того, чтобы в шаблоне игнорировались пробелы - так проще читать; и да, я НЕ проверял корректность срабатывания :))
Вообще в языке регулярных выражений есть и поиск по условию (?(?=если)то|иначе)... Нужно покурить хорошенько документацию. Думаю, что ваша задача разрешима силами только регэкспов...
Contao (ex. TYPOlight)
Каждая страница может иметь свой шаблон, свой набор подключенных СSS и скриптов. Шаблон практически любого модуля и блока на странице может быть кастомизирован полностью. Очень легко ставится. Расширяемый, активно развивающийся, много полезных доп. модулей доступно...
Отличный свободный двиг, с двумя лишь минусами: 1) ввиду гибкости требует некоторой минимальной квалификации для того, чтобы сделать на нем хороший сайт и 2) мизерное русскоязычное сообщество, поэтому вопросы (буде такие появляются) приходится задавать в буржуйском...
Уже самому интересно, что ему не нравится. Чуть позже посмотрю...
Интересный вариант с CASE :) И, по идее, полностью согласуется с логикой автора задачи.
Теперь если завернуть это в мой 2-й запрос из предложенных выше - по идее должно пройти проверку и на доп. базе, нет?
То есть если сделать так
SELECT t1.country,t1.Qty,min(t1.launched) FROM ( ... ) AS t1 LEFT JOIN ( ... ) AS t2 ON t1.country=t2.country AND t1.Qty<t2.Qty WHERE t2.Qty IS NULL GROUP BY t1.country.t1.Qty
где вместо многоточий в скобках подставить ваш запрос, то все должно сработать. Теоретически :) Проверить пока нет возможности...
Покажите запрос, которым вы исходные данные привели к таблице, приведенной в первом сообщении темы.
Это не проблема, а... скажем так... мысли автора теста по теме.
Суть "добавочной" таблицы в том, что они лепят туда NULL'ы, которые не оговорены в условии (следуя букве стандарта - по дефолту любое поле может быть пустым). И если в поле launched будут NULL'ы, то может случиться, что количество кораблей с "неизвестным годом" будет для какой-то страны наибольшим (так работает группировка).
И автор теста считает, что с точки зрения предметной области это логическая ошибка, и нужно чекать таблицу ships на null'ы в поле launched при объединении и группировке по году. Но это на самом деле вопрос спорный.
Что лучше: не увидеть битых данных или увидеть их и принять решение о степени доверия им отдельно? Я бы выбрал второе, хотя автор считает, что правильно - первое.
Интересно, почему :) См. скриншот. Данные не ваши (от балды напихал), но вроде как именно то, что нужно получаем...
UPD. Зарегистрировался, посмотрел... Может, стоило с самого начала задачу привести "как есть"? :)
