WITH Positions(pos) AS (
VALUES ROW(1), ROW(2), ROW(3), ROW(4), ROW(5)
)
, Names(name) AS (
VALUES ROW('Winslow'), ROW('Marcolla'), ROW('Contee'), ROW('Natsiou'), ROW('Finch')
)
, Colors(color) AS (
VALUES ROW('red'), ROW('white'), ROW('purple'), ROW('blue'), ROW('green')
)
, Cities(city) AS (
VALUES ROW('Bailton'), ROW('Serkonos'), ROW('Freiport'), ROW('Morley'), ROW('Danuol')
)
, Drinks(drink) AS (
VALUES ROW('absent'), ROW('coctail'), ROW('rum'), ROW('cider'), ROW('whiskey')
)
, Items(item) AS (
VALUES ROW('ring'), ROW('diamond'), ROW('order'), ROW('cigar-case'), ROW('coulomb')
)
, s AS (
SELECT DISTINCT *
FROM Positions, Names, Items, Colors, Drinks, Cities
WHERE ((name='Winslow' AND color = 'blue') OR (name!='Winslow' AND color != 'blue'))
AND
((name='Marcolla' AND pos = 1) OR (name!='Marcolla' AND pos != 1))
AND
((color='white' AND pos = 2) OR (color!='white' AND pos != 2))
AND
((color='red' AND drink = 'whiskey') OR (color!='red' AND drink != 'whiskey'))
AND
((city='Morley' AND color = 'green') OR (city!='Morley' AND color != 'green'))
AND
((name='Finch' AND item = 'coulomb') OR (name!='Finch' AND item != 'coulomb'))
AND
((city='Freiport' AND item = 'ring') OR (city!='Freiport' AND item != 'ring'))
AND
((name='Contee' AND drink = 'absent') OR (name!='Contee' AND drink != 'absent'))
AND
((city='Serkonos' AND drink = 'cider') OR (city!='Serkonos' AND drink != 'cider'))
AND
((pos=3 AND drink = 'rum') OR (pos!=3 AND drink != 'rum'))
AND
((name='Natsiou' AND city = 'Bailton') OR (name!='Natsiou' AND city != 'Bailton'))
)
SELECT t1.name, t1.item, t2.name, t2.item, t3.name, t3.item, t4.name, t4.item, t5.name, t5.item
FROM s t1
JOIN s t2 ON t2.name != t1.name AND t2.item != t1.item AND t2.color != t1.color AND t2.drink != t1.drink AND t2.city != t1.city
JOIN s t3 ON t3.name NOT IN (t1.name, t2.name)
AND t3.item NOT IN (t1.item, t2.item)
AND t3.color NOT IN (t1.color, t2.color)
AND t3.drink NOT IN (t1.drink, t2.drink)
AND t3.city NOT IN (t1.city, t2.city)
JOIN s t4 ON t4.name NOT IN (t1.name, t2.name, t3.name)
AND t4.item NOT IN (t1.item, t2.item, t3.item)
AND t4.color NOT IN (t1.color, t2.color, t3.color)
AND t4.drink NOT IN (t1.drink, t2.drink, t3.drink)
AND t4.city NOT IN (t1.city, t2.city, t3.city)
JOIN s t5 ON t5.name NOT IN (t1.name, t2.name, t3.name, t4.name)
AND t5.item NOT IN (t1.item, t2.item, t3.item, t4.item)
AND t5.color NOT IN (t1.color, t2.color, t3.color, t4.color)
AND t5.drink NOT IN (t1.drink, t2.drink, t3.drink, t4.drink)
AND t5.city NOT IN (t1.city, t2.city, t3.city, t4.city)
WHERE
-- Мы хотим вывести дам в том порядке, в котором они сидели
t1.pos = 1 AND t2.pos=2 AND t3.pos = 3 AND t4.pos=4 AND t5.pos=5
-- Дама в красном сидит левее дамы в пурпурном, но место 2 занято дамой в белом, поэтому остаются места 3 и 4
AND (
(t3.color='red' AND t4.color='purple' ) OR (t4.color='red' AND t5.color='purple')
)
-- Рядом с дамой с портсигаром сидит дама из Морли
AND
(
(t1.item='cigar-case' AND t2.city='Morley') OR
(t2.item='cigar-case' AND 'Morley' IN (t1.city, t3.city)) OR
(t3.item='cigar-case' AND 'Morley' IN (t2.city, t4.city)) OR
(t4.item='cigar-case' AND 'Morley' IN (t3.city, t5.city)) OR
(t5.item='cigar-case' AND t4.city='Morley')
)
-- Рядом с дамой с бриллиантом сидит дама из Дануолл
AND
(
(t1.item='diamond' AND t2.city='Danuol') OR
(t2.item='diamond' AND 'Danuol' IN (t1.city, t3.city)) OR
(t3.item='diamond' AND 'Danuol' IN (t2.city, t4.city)) OR
(t4.item='diamond' AND 'Danuol' IN (t3.city, t5.city)) OR
(t5.item='diamond' AND t4.city='Danuol')
)
-- Рядом с дамой из Дануолла другая дама пила коктейль
AND
(
(t1.drink='coctail' AND t2.city='Danuol') OR
(t2.drink='coctail' AND 'Danuol' IN (t1.city, t3.city)) OR
(t3.drink='coctail' AND 'Danuol' IN (t2.city, t4.city)) OR
(t4.drink='coctail' AND 'Danuol' IN (t3.city, t5.city)) OR
(t5.drink='coctail' AND t4.city='Danuol')
)
Нашёл подобное приемлемое решение на MySQL как закапиталайзить предложение
WITH d AS (
SELECT 'Lorem Ipsum is simply dummy text of the printing and typesetting industry.' s
)
, d2 AS (
SELECT *
, CONCAT(LOWER(s), UPPER(s)) s_l_u
, CONCAT('(?<=[[:space:]]|^)[a-z](?=.{', (CHAR_LENGTH(s) - 1), '}([A-Z]))') reg_exp
, CHAR_LENGTH(s) len
FROM d
)
SELECT version() ver, s, SUBSTR(REGEXP_REPLACE(s_l_u, reg_exp, '$1'), 1, len) cap
FROM d2
+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+
|ver |s |cap |
+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+
|8.0.35|Lorem Ipsum is simply dummy text of the printing and typesetting industry.|Lorem Ipsum Is Simply Dummy Text Of The Printing And Typesetting Industry.|
+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+
не проблема сгенерить 3 уникальных разделителя - между строкой и всеми заменами - между поиском и заменой - между группами замен и использовать их для построения регулярки
WITH d AS (
SELECT 'abcdaaabbbcccdcba' s
, 'a,x;bb,y;ccc,z;' repls
, 'xbcdxxxybzdcbx' test_res
)
, d2 AS (
SELECT *, CONCAT(s, '\n', repls) s_ex
FROM d
)
, d3 AS (
SELECT *
, SUBSTRING_INDEX(REGEXP_REPLACE(s_ex, '(?<search>[^\n]+)(?=.*?(\n|\n.*?;)\\\k<search>,(?<repl>[^;]+);)', '${repl}', 1, 0, 'm'), '\n', 1) res
FROM d2 d
)
SELECT s, res
, res = test_res is_correct
, VERSION() ver
FROM d3
Конечно, конечно. Код не выдерживает никакой критики, особенно в рамках обсуждения СУБД.Первая строка кода выглядит многообещающе. Вторая, уже подозрительно. Глядя на третью, уже всё понимаешь: приложение даже не пробует получить какую-то блокировку на запись, оно просто читает, хотя из второй строчки кода складывается впечатление что мы будем писать "...Save... ...inputData". Смотришь дальше и волосы на голове начинают шевелиться, тем более что у Ларавеле есть метод что бы эти строки не писать - findOrFail. А пока мы над всем этим переживали, прилетевшие данные подлетели, посмотрели насчёт published статуса и перепрыгнули на сохранение, на 12 строке... Но сохранения никого не произошло, т.к. другая сессия уже удалила эти данные. Вот и сказочке конец, а один единственный UPDATE решил бы все эти проблемы чуть более чем полностью. P.S. слава богу что не я
Моё любимое зимнее развлечение в Екб: с утра пораньше встаёшь, едешь на Уктус (20 минут от дома), бегаешь пешком в гору, катаешь на сноуборде часик-полтора, потом скатываешься к подножью горы и там ждёт Баден - горячие термы на открытом воздухе, пол дюжины различных саун + арома-парения раз в пол часа, за всё удовольствие 800р утренняя акция почти 2 часа терм с завтраком. Далее полчаса и ты дома свежий, бодрый, весёлый готов работать )))
Для себя пришёл к выводу, что для организации безопасности на уровне строк, удобнее использовать VIEW WITH CHECK OPTION. Это при SELECT'е дополнительно позволяет легко получить столбцы can_update, can_delete. При использовании встроенной RLS без дублирования логики сделать это не просто.
во многих соглашениях прикладных ЯП принято константы писать большими буквами, не думаю что у многих при виде таких констант вспоминается 386 комп и BASIC.
а кое где это будет соединение по ключу (если он есть)
Не вижу проблемы у Google:
в России 100M+ населения имеющего телефоны
каждый имеет 1+ телефон
Google брикает андроид
собирает 50р за анлок
Штраф уплачен
!!!PROFIT!!!
Мощь Postgress в красивой реализации триггеров уровня STATEMENT
MySQL 8, 1.81ms
EXPLAIN ANALYZE
....
-> Filter: ((((t4.color = 'purple') ........city))) (cost=852 rows=0.0682) (actual time=1.81..1.82 rows=1 loops=1)
Нашёл подобное приемлемое решение на MySQL как закапиталайзить предложение
не проблема сгенерить 3 уникальных разделителя
- между строкой и всеми заменами
- между поиском и заменой
- между группами замен
и использовать их для построения регулярки
Можно значительно проще и экономнее на regexp
Пример на MySQL (на PG думаю будет аналогично):
Автор явно не исследовал тренды
https://www.graphile.org/postgraphile/introduction/
Конечно, конечно. Код не выдерживает никакой критики, особенно в рамках обсуждения СУБД.Первая строка кода выглядит многообещающе. Вторая, уже подозрительно. Глядя на третью, уже всё понимаешь: приложение даже не пробует получить какую-то блокировку на запись, оно просто читает, хотя из второй строчки кода складывается впечатление что мы будем писать "...Save... ...inputData". Смотришь дальше и волосы на голове начинают шевелиться, тем более что у Ларавеле есть метод что бы эти строки не писать - findOrFail. А пока мы над всем этим переживали, прилетевшие данные подлетели, посмотрели насчёт published статуса и перепрыгнули на сохранение, на 12 строке... Но сохранения никого не произошло, т.к. другая сессия уже удалила эти данные. Вот и сказочке конец, а один единственный UPDATE решил бы все эти проблемы чуть более чем полностью.
P.S. слава богу что не я
Михаил, Михаил, столько времени прошло, а Вы тут с настолько позорным кодом выступаете в его поддержку....
В postgresql AFTER STATEMENT триггеры
Примерчик в конце
https://www.postgresql.org/docs/current/plpgsql-trigger.html
даст большую фору логике в приложении
Индексы по функции не всегда используются оптимизатором (баг MySQL)
https://bugs.mysql.com/bug.php?id=104928
в 8-30 уже на горе
а там такая красота
Моё любимое зимнее развлечение в Екб: с утра пораньше встаёшь, едешь на Уктус (20 минут от дома), бегаешь пешком в гору, катаешь на сноуборде часик-полтора, потом скатываешься к подножью горы и там ждёт Баден - горячие термы на открытом воздухе, пол дюжины различных саун + арома-парения раз в пол часа, за всё удовольствие 800р утренняя акция почти 2 часа терм с завтраком. Далее полчаса и ты дома свежий, бодрый, весёлый готов работать )))
Для себя пришёл к выводу, что для организации безопасности на уровне строк, удобнее использовать VIEW WITH CHECK OPTION. Это при SELECT'е дополнительно позволяет легко получить столбцы can_update, can_delete. При использовании встроенной RLS без дублирования логики сделать это не просто.
Это что-то меняет?
SQL
выполнение/редактирование кода в консоли
чтение запросов в логе
во многих соглашениях прикладных ЯП принято константы писать большими буквами, не думаю что у многих при виде таких констант вспоминается 386 комп и BASIC.
оптимизатор MySQL умеет такое кушать, но тоже оч ограниченно
Очень нравятся рогалики, в последнее время залип в The Binding of Isaac, уже год оторваться не могу
не надо сравнивать с EAV, спроектируйте нормальную структуру и сравните с ней, читаемость кода, быстродействие, консистентность