Не совсем понятно, какая задача изначально решается. Скорей всего, поиск процедур, использующих таблицу или поиск таблиц, используемых в процедуре.
Через t-sql это можно получить одним запросом, см. sys.objects, object_definition, sys.sql_expression_dependencies.
Не пойму, почему дискуссия ушла в обсуждение того, есть ли тестировщик?
Изначально говорится, что нужно обратиться «к человеку, сообщившему о проблеме». А это не обязательно тестировщик.
Имхо, это элемент вежливости со стороны автора запроса — написать подробно (в разумных пределах, принятых конкретно в этой организации), как получилась проблема. Как показывает опыт, часто разработчик даже и не додумается до такого способа :)
1. Robert Sheldon — довольно известный специалист по MS SQL.
2. Внутреннее представление здесь приведено всего лишь для изучения, а не для использования в коде.
3. «Если нужно хранить datetime, а проверять эффективно по индексу чисто дату — делаем computed persisted поле типа date, и в формуле пишем convert(date, XXX, 1) — и по нему уже строим индекс. Вот этому учить надо с самого начала. „
Как раз так не надо.
Проверка на диапазон с начала по конец суток — типовая задача, городить на каждое поле datetime вычисляемый столбец с индексом — ненужный overhead.
Интересно. Но — судя по тому, что выпавшая страница все равно числилась, как принадлежащая этой таблице — можно было просто пересоздать кластерный индекс. Все данные бы заново легли по страницам, с обновлением всех связей, как вертикальных, так и горизонтальных.
Если сохранился еще поврежденный бэкап, можете провести эксперимент.
Эх, автор, зря вы про тимбилдинги и сплавы начали, это, действительно, не всем подходит.
Идеи-то правильные — надо управлять настроем коллектива, нельзя пускать на самотек. Иногда ложка дегтя портит коллектив.
Жена не работает, дети в садик/школу не ходят, что так просто взяли и поехали — не в отпуск, а в командировку?
Нет, это все художественный вымысел. Стеб, чтоб некоторые посмотрели на себя и свои ценности со стороны. «Деревня дураков» на современный IT-лад.
Вполне возможны визуальные инструменты быстрой разработки, которые будут учитывать «от 4к. на десктопах до мобильных 5 дюймов, а также планшеты и мобильные с их альбомной развёрткой, в которой всё также должно красиво отображаться».
Кроме того, далеко не всем надо, чтоб работало на большом зоопарке устройств.
Автор совершенно правильную мысль озвучил — инструменты разработки интерфейса находятся на уровне «ассемблера» по трудоемкости и скорости разработки.
Когда придется в чужом коде разбираться (а это будет часто), вспомните матан, он вам цветочками покажется :)
Если серьезно, такие предметы приучают не бояться долгих вдумчивых исследований, это плюс.
У нас на 1 курсе (а было это аж в 1992 году) такая вот тетенька 50-60 лет сказала — кому курс кажется «фигней», приходите сдавайте экстерном, но пока еще никто не пришел.
И потом 2 года эта тетенька клала нас на лопатки в написании алгоритмов.
О проталкивании условий в подзапрос — у меня работает (pg 11), если изменить запрос, чтоб использовался индекс:
SELECT SUM(cc.ls)
FROM Product pr
LEFT JOIN (SELECT MAX(shipment) AS ls, s.product
FROM shipmentDetail s
GROUP BY s.product) cc ON cc.product=pr.id
WHERE pr.id = 1; -- name LIKE 'Product 86%';
то есть, оно в принципе есть.
А как оно должно в вашем запросе работать, какой предикат протолкнется в подзапрос, если условие по имени продукта, а подзапрос про имена продуктов не знает?
Вот для сравнения запрос с lateral и план, работает только по отфильтрованным строкам.
SELECT SUM(cc.ls)
FROM Product pr
LEFT JOIN lateral ( SELECT MAX(shipment) AS ls
FROM shipmentDetail s
where s.product = pr.id
) cc on true
WHERE pr.name LIKE 'Product 86%';
Разобраться бы и посмотреть планы.
«абстрагировать разработчика от особенностей хранения данных» — sql-разработчик должен понимать, что под капотом view — сканы или поиски по индексу.
В вашем случае вместо тяжелой оконной конструкции почему бы не применить cross apply или табличную функцию —
select o.ObjectID, x.LastStatus
from MyObjects o
cross apply ( select top 1 s.Status as LastStatus
from MyObjectStatuses s
where s.ObjectID = o.ObjectID
order by s.Date desc -- любое нужное условие
) x
Зачем делать материализованное представление, чтоб потом упереться в его ограничения. Материализованное представление — самый негибкий способ поддержки синхронности исходных и вычисленных данных, используется в простейших случаях. В приближенных к жизни сценариях синхронизация делается отдельным кодом, не обязательно синхронно с изменениями исходной таблицы.
Какие-то странные выводы про неудобства табличных функций в cross apply — вполне можно и параметры функции использовать, и далее во where накладывать условия — inline-функция раскроется в запросе, и все условия сработают.
Проблема N+1 в данном случае высосана из пальца. Вопрос привычки и опыта.
Триггеры уровня оператора в postgreSQL вполне себе поддерживают получение старых и измененных данных — иначе, действительно, зачем они нужны, этакий чемодан без ручки.
1. Можете подробнее описать — какой получился суммарный объем всех объектов?
Пусть ненормализованный документ порядка 1 Кб, т.е. всего 100 Гб, и фуллскан быстро работает?
2. Вы говорите про индексы для запросов, не требующих скана — но они же не бесплатны. По сути, индекс — это частичная копия данных. Из JSON достали часть атрибутов и положили отдельно, т.е. уже какая-то нормализация. Весьма ограниченная при этом.
Поправьте меня, может, я не понимаю.
Все эти select for update — это же про то, как блокировать данные в транзакции при изменении (т.е. сначала select, какая-то обработка, тут же update). А не про то, что Вася открыл окно, select-ом for update выбрал и заблокировал строку на длительное время, а потом через час сделал update.
В вопросе речь идет про non-lock concurrency control. Это когда на уровне логики приложения проверяется, не изменена ли запись кем-то относительно момента, когда мы ее вывели в окно. И это не в транзакции.
Мне кажется, это не вопрос о PostgreSQL.
— Как проверять, когда со строкой работают несколько пользователей? Какие варианты есть?
— Во-первых, можно перед показом строки в форме вЫчитать значения всех колоночек и убедиться, что они не поменялись. Второй вариант, более удобный: высчитать хэш на всех
колонках, тем более, что колонки там могут быть большие и толстые. А хэш не такой большой.
Не совсем понятно, какая задача изначально решается. Скорей всего, поиск процедур, использующих таблицу или поиск таблиц, используемых в процедуре.
Через t-sql это можно получить одним запросом, см. sys.objects, object_definition, sys.sql_expression_dependencies.
Изначально говорится, что нужно обратиться «к человеку, сообщившему о проблеме». А это не обязательно тестировщик.
Имхо, это элемент вежливости со стороны автора запроса — написать подробно (в разумных пределах, принятых конкретно в этой организации), как получилась проблема. Как показывает опыт, часто разработчик даже и не додумается до такого способа :)
— Вжик! — сказала пила, и бревно пополам.
— Ух ты! — сказали мужики и положили бревно потолще.
— Вжжжик! — сказала пила и… бревно пополам.
— Ого! — сказали мужики и положили рельсу.
— Вжж-крях! — сказала пила и поломалась.
— Ага!!! — сказали мужики, — То-то же…
пусть есть поле MyDate datetime с индексом по нему.
2. Внутреннее представление здесь приведено всего лишь для изучения, а не для использования в коде.
3. «Если нужно хранить datetime, а проверять эффективно по индексу чисто дату — делаем computed persisted поле типа date, и в формуле пишем convert(date, XXX, 1) — и по нему уже строим индекс. Вот этому учить надо с самого начала. „
Как раз так не надо.
Проверка на диапазон с начала по конец суток — типовая задача, городить на каждое поле datetime вычисляемый столбец с индексом — ненужный overhead.
Интересно. Но — судя по тому, что выпавшая страница все равно числилась, как принадлежащая этой таблице — можно было просто пересоздать кластерный индекс. Все данные бы заново легли по страницам, с обновлением всех связей, как вертикальных, так и горизонтальных.
Если сохранился еще поврежденный бэкап, можете провести эксперимент.
Эх, автор, зря вы про тимбилдинги и сплавы начали, это, действительно, не всем подходит.
Идеи-то правильные — надо управлять настроем коллектива, нельзя пускать на самотек. Иногда ложка дегтя портит коллектив.
Нет, это все художественный вымысел. Стеб, чтоб некоторые посмотрели на себя и свои ценности со стороны. «Деревня дураков» на современный IT-лад.
Кроме того, далеко не всем надо, чтоб работало на большом зоопарке устройств.
Автор совершенно правильную мысль озвучил — инструменты разработки интерфейса находятся на уровне «ассемблера» по трудоемкости и скорости разработки.
Если серьезно, такие предметы приучают не бояться долгих вдумчивых исследований, это плюс.
И потом 2 года эта тетенька клала нас на лопатки в написании алгоритмов.
то есть, оно в принципе есть.
А как оно должно в вашем запросе работать, какой предикат протолкнется в подзапрос, если условие по имени продукта, а подзапрос про имена продуктов не знает?
Вот для сравнения запрос с lateral и план, работает только по отфильтрованным строкам.
посмотрите пример 42.7 про триггер уровня оператора. Да, transition tables, все работает.
«абстрагировать разработчика от особенностей хранения данных» — sql-разработчик должен понимать, что под капотом view — сканы или поиски по индексу.
В вашем случае вместо тяжелой оконной конструкции почему бы не применить cross apply или табличную функцию —
Пусть ненормализованный документ порядка 1 Кб, т.е. всего 100 Гб, и фуллскан быстро работает?
2. Вы говорите про индексы для запросов, не требующих скана — но они же не бесплатны. По сути, индекс — это частичная копия данных. Из JSON достали часть атрибутов и положили отдельно, т.е. уже какая-то нормализация. Весьма ограниченная при этом.
Все эти select for update — это же про то, как блокировать данные в транзакции при изменении (т.е. сначала select, какая-то обработка, тут же update). А не про то, что Вася открыл окно, select-ом for update выбрал и заблокировал строку на длительное время, а потом через час сделал update.
В вопросе речь идет про non-lock concurrency control. Это когда на уровне логики приложения проверяется, не изменена ли запись кем-то относительно момента, когда мы ее вывели в окно. И это не в транзакции.
Мне кажется, это не вопрос о PostgreSQL.
Серьезно, это вопрос на конференции?