← All posts tagged SQL

alex0b
MS SQL мутанты Запускать профайлер запросов само по себе недоразумение. Глупое и неприятное занятие. Очевидно, что решишь сохранять лог в запросов в таблицу, вероятно на тот же сервер, так как файлом или гуем пользоваться можно только в случае если ты — наномутант и у тебя пикозапросы выполняющиеся фемтосекунды (иначе тупо не помещается в окошко, а копипаст блока строк можно выполнить ограничено и не в штуках.. хз.. 1 кб буфер?). Чтобы включить фильтрацию запросов по базе, надо знать, что этот фильтр активируется очень нетривиально и находится пониже спины, достаточно глубоко. А так профайлер перехватывает все запросы по серверу. Если удумать сменить шаблон, то слетает фильтр по умолчанию, в котором сказано игнорить активность самого профайлера. Который там же находился и о его существовании можно было только догадываться. Т.е. достаточно всего одного запроса, чтобы дальше профайлер занялся профилированием того как он профилирует запись профилированных запросы в журнале профайлера. Долго и весьма настойчиво.
alex0b
MS SQL Приезжали, впаривали 2016. Обещали без маркетингового булшита, но за три часа я как раза три раза и уснул. Может быть асинхронную репликацию в группе доступности куда и прикрутим (и то не в продакшен, а для цели разработки) а остальное и применять без надобности
alex0b
MS мантра SQL ЯДибил Надо читать документацию до конца (хотя бы статьи). last_value() совсем не последнее, а если последнее, то не в той выборке, а если и в той, то всё равно не то значение. OVER ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ཨོཾ་མ་ཎི་པ་དྨེ་ཧཱུྃ།
alex0b
SQL dev Надо больше спать. Схема описанная в #2700053 не работает, как в общем случае так и конкретно для InnoDB. Рандомная вставка в таблицу со строковым PK — это не "медленно", а невозможно медленно.
alex0b
? SQL dev Жуйк, подскажи почему весь мир (и я в том числе) для налепливания меток к контенту делает схему типа:
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 рукожопие В SQL Server 2008 DATEDIFF неявным образом приводит строковые литералы к типам datetime2а еще неявно заставляет разработчиков создавать визуальные компоненты Label1 и Button23 .. поубивал бы
alex0b
work слоупок SQL ЯДибил всю жизнь думал, что where выполняется до join. потом минут пять думал, что сия девиация косается только t-sql. уже несколько десятков секунд знаю, что и идеологически верном pg — таже пестня. посыпаю голову пеплом самое время цитировать слоника в домене:

Заранее отвечаю на возможные вопросы:
1. Не помню что пил и курил.
2. Да, долбоеб.
3. Первую программу на С++ написал в 2000 году.
4. Да, набрали по объявлениям
5. Да, надо уволить
alex0b
SQL рукожопие Давненько я не трогал t-sql... Для меня открытие, что нельзя трогать RAISERROR в UDF. Лучше бы я для себя открыл ариель или блендамент.. идиоты, ну че так? теперь извращаться