- 1
(CASE WHEN "order".payment_type = 1 AND payed = 0 THEN 0 ELSE 1 END) = 1-
SQL / Говнокод #20102
−41
Одно из индусских условий в WHERE. Выражение вполне можно сократить до такого:
или такого:("order".payment_type <> 1 OR payed > 0)
NOT ("order".payment_type = 1 AND payed = 0)Запостил:
jbot,
31 Мая 2016
Follow us!
Сие не ГК, сие эталон продуманности, умения решать задачи шире поставленных. Гарбер рыдал бы слезами восторга и умиления.
Неплохой букварь, правда
ПОНИМАНИЕ SQL" о
Вот вроде есть
Choose the right transaction isolation level and concurrency model
Take control over query plan caching and reuse
https://www.microsoftpressstore.com/store/microsoft-sql-server-2012-internals-9780735658561
http://www.yaplakal.com/forum3/topic1386421.html?hl=
Ставьте лойсы
че за херня?
Take control over query plan caching and reuse
Rule the world
Дык там у каждой субд ещё и своё понимание этих уровней...
Тот же слоник, к примеру, вообще не умеет в read uncommitted. А на repeatable read, емнип, он даёт намного более строгую гарантию, чем надо по стандарту - снепшот на момент первого запроса в транзакции.
Так вот на read uncommited он обязан не гарантировать ничего. Что он и делает. А что по-факту uncommited read не виден никогда -- так это не его проблема)
Интерфейс называется ANSI SQL, там есть описание всех четырех уровней
Вот кстати в этом плане Gruber хорош: он имплементейшен-агностик довольно
На ANSI SQL ты только лабу напишешь, и то не факт...
Я не спорю что в реальных проектах есть код (ну процентов 20) который надо писать с учетом конкретной БД, просто знать стандарт все равно нужно.
Например ты можешь оптимизироваться под конкретный компилятор или проц, но это не избавляет тебя от знания ANSI C или JMM, правда?
Вот только его никто не поддерживает, лол.
> SQL/XML
А где йосон иль еще какой стандарт?
> SQL/PSM
На самом деле круто. Многое есть. Стандартную библиотеку бы еще стандартизировали... Но даже кресты в это не могут, по капле из моря(
> Дык там у каждой субд ещё и своё понимание этих уровней...
snapshot isolation level + sp_getAppLock. Остальное не нужно, сирисли.
А есть хоть одна реляционная бд, где можно выбрать тип индекса? Ну кроме кластерный\не кластерный. По моему нет, так что не особо полезно. И вообще даже нет возможности выбрать индекс case sansative индекс или нет. Не то чтоб какие-нибудь хеш индексы или трии индексы
Няшный постгрес.
Но в слову в постгресе больше всего тонких моментов аля уб
много интересных фишечек, опережающих pl/sql
а вот по функциональности в ынтерпрайзных задачах частенько посасывает ораклу
буквально на днях колхозил вполне логичный для субд функционал, аналогичный оракловому scheduler_job
dblink постгресовый удобен как говно, mat view как говно, даже партиционирование и то ведет себя при инсертах как говно и ломает ожидания хибернейту
нет ничего идеального
создание concurently индекса - сплошной уб
https://docs.oracle.com/cd/B19306_01/server.102/b14200/ap_examples001.htm#i690409
а уж про case insensitive - индексируй lower(foo), и селекти lower(foo), чтобы оптимизатор индекс цеплял, это будет годно для любой субд с поддержкой function-based indexes, вместо того, чтобы запоминать какие-то (нестандартные?) параметры создания регистронезависимого индекса в конкретной субд
кстати, внутри оракла function-based сам по себе создает виртуальную колонку к таблице, она просто заодно ещё и скрытая
все новые проекты последние года полтора мы зачинаем строго на постгресе, по многим причинам
я просто указываю на досадные и (внешне) несложные вещи, недоделанные в постгресе, с надеждой, что они когда-либо исправятся
в оракле тоже совсем не все так сладко, но тот факт, что за десяток проектов я в горячке постгрес не удалил, заменив его ораклом, а методично преодолевались проблемы худо-бедно, тоже о чем-то да говорит
оракл версии стандарт и выше покупать обязательно, если ты его применяешь в продакшен целях
никакой анальной активации там нет, можно на тестовые стенды ставить сколько угодно
активация заключается в доступе к металинку за патчами и доками об ошибках субд (а такие бывают даже в оракле)
также есть экспресс едишен, он лимитирован, но официально бесплатен, матрицу сравнений редакций можешь посмотреть на сайте
захотели медиапомойку с автогенерацией миниатюр и транскодинга (пресловутое mp4+webm в нескольких разрешениях из оригинала) в проекте сделать через "блобы"
заебенили хорошую продуманную схему, непосредственно хранилище распартиционировано, мухи от котлет отделены
оказалось везде минное поле
bytea хоть и хранится там где надо (TOAST раскладывается по партициям наравне с материнской таблицей), но протокол его походу искейпит вдоль и поперек, и вместо 100МБ файла гоняется трафик в 2-3 раза бОльший, да и ограничение имеет в 1GB (как бы, ага)
oid (это типа постгресный настоящий LOB) хранится в пизде, одна системная таблица на всю БД, никакого партиционирования уже тут нет, нельзя тут хранить сотни тыщ файлов, больших и малых
и даже хер бы с ними с недостатками bytea, но ведь драйвер его внатуре гоняет через буферы сессии, и на инсерте файла чуть большем, чем 128M постгрес киляет сессию по OOM, невзирая, например, на настройки shared_memory = 1GB
вот такая вот enterprise-ready СУБД
То ли дело MySQL.
использование более строгих должно сопровождаться уверенностью, что это реально необходимость, а не подпирание костылями хуево спроектированной схемы или хуево продуманной логики
ты там выше рассказывал про создание индекса онлайн в постгресе - ну я так пони у тебя там есть здоровенные таблицы на миллионы и миллиарды записей, которые дрочатся по сотне апдейтов в секунду, поэтому тебе нельзя потратить минуту в интервал обслуживания, надо именно онлайн
ну так вот, хорошо работает сериалайзед на этих таблицах в охулиард? или всё же проще строки лочить? что сильнее тормозит?
> в стандарте описаны 4 уровня изоляции
воспользуйся ими и ты
Это что-то из M$$QL вроде.
З.Ы. Кстати, у постгреса repeatable read это и есть снимок на момент первого запроса в транзакции...
READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
сериалайзед это когда все последовательно. упоротый лок на все, если юзаешь общие таблицы между запросами
снапшот - снимок закомиченного. спокойно все параллельно читается и апдейтится. если параллельно апдейтить одну строку с другим запросом, то запросу с меньшим приоритетом не везет и он отваливается и надо повторять, если это еще актуально
мне лень доки читать, объясни на пальцах
у меня есть таблица А и таблица Б, в которой внешний ключ на А
транзакция 1 вставляет в таблицу А строку со значением id = 10, его еще нет, ничего не нарушается, вставляет в таблицу Б две строки, которые ссылаются на A.id=10
параллельно с этим транзакция 2 тоже вставляет в таблицу А строку с тем же значением id, и вставляет в таблицу Б три строки, ссылающиеся на А.id=10
что произойдет после коммита обеих транзакций?
она же не видит изменений первой транзакции, ты же сам говоришь
На read committed - нинужно.
Пример кода в студию.
Ну бля, хуй тоже можно сломать...
второй запрос на изменение этой строки её перезапишет сразу, как только субд снимет блокировку этой строки
представь себе личный кабинет и свое ФИО в нем, ты зашел с двух разных устройств, нажимаешь редактировать, и почти одновременно посылаешь на сервер "обнови мне их на вот это новое значение" - какое останется в итоге? которое придет вторым
и серверу не важно, что второе пришло на миллисекунду позже или на 6 месяцев позже первого
но это совсем не о том, о чем я выше писал
> следущий стэйтмент в транзакции тебе может вернуть данные, не те, что были на начало транзакции
такое может быть, если ты сначала поселектил 10 строк в таблице А по конкретному условию, на основе них поселектил 20 строк в таблице Б, это всё обработал, а потом в той же транзакции за каким то хером снова полез селектить из таблицы А с тем же условием и получил 11 строк - вот и вопрос, нахера ты лезешь 2 раза за теми же строками
Так вот из-за этого можно сломать инвариант, например когда
if exist (select ...) then insert ...
Первый селект покажет один результат, а второй инсерт уже будет инсертить в измененную в другой транзакции таблицу с уже измененным условием if. Состояние гонки. И может даже эксепшен за дубликаты первичного ключа выкинуть.
А merge в sql server поломан и не помогает)))
да, только if not exists
в этом случае надо ставить лок на таблицу в нужном режиме (чтобы её могли, например, читать, но не могли менять), делать свои дела как можно быстрее и снимать лок
а если ты все же имел в виду if exists, то есть более мягкий лок - select for update
Транзакции должны быть резкими и острыми как бритва. Раз у тебя транзакции часами висят - ну понятно, откуда дедлоки и прочее говно.
только цикл тут причем?
чинить надо приложение, а не делать несколько попыток
1. Бывает травма, которую называют переломом пещеристого тела. Возникает, когда к эрегированному члену прикладывают нагрузку в направлении, перпендикулярном его оси.
Возле основания полового члена в пещеристом теле разрываются перегородки, и кровь растекается там, где её не ждут.
2. У очень мелких животных (вроде грызунов) и у очень крупных (вроде китообразных) есть бакулюм. Внешне бакулюм неотличим от кости, хотя по происхождению является отложением солей в пещеристом теле.
Мелким животным тяжело поддерживать половой член в напряжённом состоянии из-за того, что у них мало крови, а крупным тяжело из-за того, что сам член тяжёлый. Их выручает бакулюм, придающий члену твёрдость.
Да, бывает перелом бакулюма.
потому что сравнение выражения с полем, с точки зрения SQL, есть еще большее говно.