← All posts tagged SQL

alex0b
dev Пришлось вспомнить говноскилы: распарсить xml на php и нагенерить mysql-совместимого. Прости мне, ибо я нагавнокодил.
alex0b
dev опарыши Здоровая складская система, написанная на .NET, данные в MS SQL Server. Данные в штатные гриды затягиваются, понятно дело, датасетами. Схема датасета и маппинг на вьюшеньку читается из xsd, лежащего рядом — судя по всему в рукопашную запиленного. И тут же хардкодом подчикивается и допиливается.
Из особо понравившегося: есть функция которая накладывает фильтры на датасет, причем принимает параметрами критерии и фильтр по агрегатам. Критерии эти (фильтр) типа датасет, где каждая строка это кусок предиката, а столбцы суть элементы предиката (оператор, операнды, скобки). Имена столбцов захардкожены, разумеется. "Having" претерпевает аналогично. Чуть поодаль, но не далее пары строк, обычно идет вызов второй функции, которая добавляет к совокупным фильтрам уже строковые ExtraFrom и ExtraWhere.
alex0b
MS SQL Приезжали, впаривали 2016. Обещали без маркетингового булшита, но за три часа я как раза три раза и уснул. Может быть асинхронную репликацию в группе доступности куда и прикрутим (и то не в продакшен, а для цели разработки) а остальное и применять без надобности
alex0b
MS мантра SQL ЯДибил Надо читать документацию до конца (хотя бы статьи). last_value() совсем не последнее, а если последнее, то не в той выборке, а если и в той, то всё равно не то значение. OVER ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ཨོཾ་མ་ཎི་པ་དྨེ་ཧཱུྃ།
alex0b
dev рукожопие Когда люди выставляют холодильник зимой на улицу — это нормально. Когда они выставляют API в виде JSON­ RPC — это нормально. Но когда они заявляют, что "Функционально протокол реализует команды манипуляции данными DML языка SQL, точнее PostgreSQL диалекта ( postgresql.org )", начинаешь опасаться. Черви безумия.
alex0b
Linux ? PostgreSQL dev C Удивился без музыкальных инструментов: мои хранимочки написанные на C перестали собираться спустя пару лет. Точнее линковаться. Медитация над выхлопом gcc утомила и заставила найти простое и правильное решение в документации самого pg. А еще я понял, что ни фига не понимаю в этих gcc\Makefile и прочей прилежащей лабуде. Не то чтобы я планирую отряхнуть пыль с бороды на свитер и снова взяться за суровые, настоящие яп, но только теперь под правильной ОС. Нет, как раз предпочту держаться интерпретируемых, а понять принцип хочется из любопытства. Так вот, граждане, подскажите — кто что сможет: что-нибудь почитать кратенькое, поверхностное, но идейно верное про gcc, вот это всё?
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
MySQL рукожопие Ну как так? При truncate внешние ключи учитываются, а тригер на удаление на очищаемой таблице не вызывается. Для каких целей это нужно? Одноногие наркоманы пилят ноги другим: что inserted_id, что affected_rows, что транзакции, что блокировки. Какой нахер кластер, тут бы acid осилить.
Пересмотрел свои записи с тегом *mysql — много плакал.
alex0b
MySQL рукожопие Пишу: truncate table ...; А оно мне: Cannot delete or update a parent row: a foreign key constraint fails. Казалось бы, идиотизм? Ан-нет, стоит учесть еще: "Triggers currently are not activated by foreign key actions" чтобы почувствовать весь вкус победы над здравым смыслом.
alex0b
dev IPv6 C pgsql Всем хорош pgsql, поддерживает ipv6 из коробки (хотя наверно уже все умеют давно), функции годные есть. Только вот если вот захочется выполнить какие-то операции с подсетями, например хотябы сформировать адрес следующей подсети (+1) — хрен что выйдет. Ойпивэ6 зело больших размеров, привести его к чему-нибудь не случится, выкусить кусок тоже. А я на сишечке не быдлокодил с институтика. Вроде осилил: pastebin.com . С удовольствием почитаю всех, кто захочет рассказать откуда у меня руки растут.
alex0b
dev pgsql happiness Сколько лет трогаю пг, и вот наконец пригодился FOR EACH STATEMENT триггер, Гармонично, без притягивания за уши требований к инструментарию. Добро.