это не "просто (очень) большая таблица" там под капотом целая in-memory база данных (можете загуглить - vertipaq) аналогов которой на рынке по пальцам одной руки пересчитать.
ну не совсем. Я бы сказал что эксель это ОЧЕНЬ сложный продукт, который совершенствовался десятилетиями! Нельзя просто взять и скопировать его, и чтобы он так же хорошо работал
и что? временная таблица с уникальным констрейнтом?? тогда загрузка не пройдет - свалится на первом же дубле. А если без констрейнтов - то это та же самая задача.
хорошая теория, жаль с реальной жизнью не совпадает.
В реальности полно случаев когда бывают полные дубликаты и по порядковым номерам, и по штампам времени, и по чему угодно. И я даже могу сказать из-за чего. Из-за того что где раньше по потоку данных, тоже стоит такой алгоритм дедупликации - и вместо гарантированной одной записи, выдает теоретическую одну, а на практике когда две, а когда и больше.
эти три запроса не эквивалентны, если у нас history_field не уникальна
то первый и третий запросы не смогут вернуть одну запись, второй сможет, надо только RANK на row_number заменить
по перформансу, если на history_field навесить индекс, первый запрос можно неплохо ускорить (особенно с фишкой замены max на order by с limit 1), третий будет nested loop (без сортировки) , но который скорее всего даже медленне сортировки изза условия t1.history_field > t2.history_field которое индексом не ускорить
Откуда такой миф??? С чего это вдруг разница, да еще и в разу, если и там и там - одна единственная сортировка по колонкам указанным либо в ROW_NUMBER либо в ORDER BY в запросе с DISTINCT ON
ну пару лет назад казалось что рынок поиска ВСЕ. Монополизирован гуглом тотально. Ан сейчас оказывается чатГПТ конкурирует с поиковиком и успешно. Это я к чему, к тому что новые ниши могу возникнуть там где и не ждал никто. Даже в смартфонах
Так бывает на всех рынках - лучшие становятся монополистами, монополисты бронзовеют и отрываются от нужд людей - спрос остается неудовлетворенным, а значит появляются незанятые ниши - ну и появляются новые игроки которые рады будут занять эти ниши - и т.д.
ну-ну, полный Zero Trust не возможен, не выдумывайте
если тебя это утешит, то алгоритмы гуглкарт тоже плохо умеют определять границы ограничения скорости.
это не "просто (очень) большая таблица" там под капотом целая in-memory база данных (можете загуглить - vertipaq) аналогов которой на рынке по пальцам одной руки пересчитать.
ну не совсем. Я бы сказал что эксель это ОЧЕНЬ сложный продукт, который совершенствовался десятилетиями! Нельзя просто взять и скопировать его, и чтобы он так же хорошо работал
и что? временная таблица с уникальным констрейнтом?? тогда загрузка не пройдет - свалится на первом же дубле. А если без констрейнтов - то это та же самая задача.
угу, не говоря уже о том что у них перформанс ужасный
ой, к тебе CSV файл пришел, надо загрузить в базу с дедубликацией. Что будешь делать??
оказывается одна цифра плохо подходит для описания нагрузки современных процессоров с кучей ядер, потоков, гипертредингов и прочая, и прочая
План у любого коррелированного подзапроса ужасен. Это антипаттерн всегда, если у вас хоть сколько нибудь много строк во внутренней таблице
хорошая теория, жаль с реальной жизнью не совпадает.
В реальности полно случаев когда бывают полные дубликаты и по порядковым номерам, и по штампам времени, и по чему угодно. И я даже могу сказать из-за чего. Из-за того что где раньше по потоку данных, тоже стоит такой алгоритм дедупликации - и вместо гарантированной одной записи, выдает теоретическую одну, а на практике когда две, а когда и больше.
эти три запроса не эквивалентны, если у нас
history_fieldне уникальнато первый и третий запросы не смогут вернуть одну запись, второй сможет, надо только RANK на row_number заменить
по перформансу, если на
history_fieldнавесить индекс, первый запрос можно неплохо ускорить (особенно с фишкой замены max на order by с limit 1), третий будет nested loop (без сортировки) , но который скорее всего даже медленне сортировки изза условияt1.history_field> t2.history_field которое индексом не ускоритьну вот товарищ явно ни питоном ни SQL не владеет. Поэтому в аналитику и не может
стопе, а они продукт-оунера нанимают, или девелопера??????
Откуда такой миф??? С чего это вдруг разница, да еще и в разу, если и там и там - одна единственная сортировка по колонкам указанным либо в ROW_NUMBER либо в ORDER BY в запросе с
DISTINCT ONЕсли знать оконные функции, эти все костыли с
DISTINCTONне нужны.А оконные функции знать имхо явно полезнее, ибо они есть везде. А это чисто постгресовая фича
что "да" ???
опять споры по микросервисы vs монолит
ну пару лет назад казалось что рынок поиска ВСЕ. Монополизирован гуглом тотально. Ан сейчас оказывается чатГПТ конкурирует с поиковиком и успешно. Это я к чему, к тому что новые ниши могу возникнуть там где и не ждал никто. Даже в смартфонах
Так бывает на всех рынках - лучшие становятся монополистами, монополисты бронзовеют и отрываются от нужд людей - спрос остается неудовлетворенным, а значит появляются незанятые ниши - ну и появляются новые игроки которые рады будут занять эти ниши - и т.д.
В смысле нет правил?? Законов написано - читать не успевают.