← All posts tagged SQL

alex0b

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

alex0b

Надо читать документацию до конца (хотя бы статьи). last_value() совсем не последнее, а если последнее, то не в той выборке, а если и в той, то всё равно не то значение. OVER ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ཨོཾ་མ་ཎི་པ་དྨེ་ཧཱུྃ།

alex0b

Надо больше спать. Схема описанная в #2700053 не работает, как в общем случае так и конкретно для InnoDB. Рандомная вставка в таблицу со строковым PK — это не "медленно", а невозможно медленно.

alex0b

Жуйк, подскажи почему весь мир (и я в том числе) для налепливания меток к контенту делает схему типа:
posts (pk id, text content)
tags (pk id, varchar tag : unique_idx)
tags_posts (pk tag_id + post_id, fk(tags), fk(posts))

Чтобы найти все посты по метке X, надо выполнить что-то типа:
select p.* from posts p inner join tags_posts tp on p.id=tp.post_id inner join tags t on t.id=tp.tag_id where t.tag = X;
Как я понимаю, тут
— 1 скан по tag : unique_idx
— 2 inner join по индексам
+ что бы вывести список всех меток к посту надо выполнить еще один запрос с джоином.

Причем мир использует эту схему универсально, всегда и везде. А если скажем для случаев расчитанных на быструю выборку и допускающих медленную вставку/обновление сделать:

posts (pk id, text content, text post_tags) // post_tags — разбиваются по разделителю при формировании страницы
tags_posts (pk varchar tag + post_id, fk(posts))

select p.* from posts p inner join tags_posts tp on p.id=tp.post_id where tp.tag = X;
Так должно занимать больший объем за счет дублирования строк, но казалось бы должно быстрее выполняться и все данные достаются одним запросом. Что я упускаю?
В случае, если метками помечаются разные виды контента в выборке поста/картинки/бульбы по тегу — ничего не меняется — структуры запросов сохраняются. Для построения единного облака придется делать все таки общий словарь с счетчиком использования, что так же увеличит объем хранения, и приведет схему подобию первой, только pk в 2-х таблицах будут строчные. Неужели рост объема снижает весь профит от быстрой выборки?

alex0b

В SQL Server 2008 DATEDIFF неявным образом приводит строковые литералы к типам datetime2а еще неявно заставляет разработчиков создавать визуальные компоненты Label1 и Button23 .. поубивал бы

alex0b

всю жизнь думал, что where выполняется до join. потом минут пять думал, что сия девиация косается только t-sql. уже несколько десятков секунд знаю, что и идеологически верном pg — таже пестня. посыпаю голову пеплом самое время цитировать слоника в домене:

Заранее отвечаю на возможные вопросы:
1. Не помню что пил и курил.
2. Да, долбоеб.
3. Первую программу на С++ написал в 2000 году.
4. Да, набрали по объявлениям
5. Да, надо уволить