Ну значит вы никогда понастоящему не работали с данными. Потому что реляции по ключам реальны только там где они существуют с первого дня, а в жизни все немного иначе. В жизни есть дубли, есть поврежденные и фрагментированные данные. Данные которые вы получаете, но не управляете. У нас основная бд с которой работает подразделение получает данные с оборудования через xml дампы и принтауты консольных команд. Каждый день потенциально новый тип у существующей колонки, и появление новых. Никаких первичных ключей или признаков уникальности не предусмотрено в принципе. Максимум этой базы - синтетические id которые корректны только от аплоада до аплоада.
Тоже самое с картографическими данными коих у нас великое множество
Проблема в том, что подход из статьи только увеличивает энтропию и количество обьектов.
Ответ: неотличимо от ручного джойна
Что характерно нет никакого этому подтверждения, потому что похоже в статье отсутствует план запроса до-после, или какой-либо бенчмарк. У джентельменов принято верить на слово, и если в pg в все именно так, то это замечательно, но к примеру в sql server использование методов.. смерти подобно потому что код в большинстве случаев не разматывается оптимизатором, как в случае вью или сахарных CTE.
не компонуется в цепочки вида client(document(di))
Лично мое мнение, как человека который последние 10 лет только и делает, что пялится в SQL.. за такое надо немного бить, может быть даже палкой. Во первых за то что это здорово снижает читаемость и понимание кода. Я абсолютно уверен, что пять одинаковых ON не многословность, а явное намерение.
Во вторых, за нейминг в приведенном примере. Табличные и скалярные методы опять же должны выражать намерение в названии.. а тут его нет. В третьих..
CREATE FUNCTION client_document_list(profile) RETURNS SETOF document LANGUAGE sql STABLE PARALLEL SAFEAS $$ SELECT * FROM public.documentWHERE (client_id) = (($1).client_id) $$;
.. я не большой специалист в Pg, но это выглядит так словно мы одной нагой залезли в N+1 проблему. Делать это преимуществом по сравнению с JOIN.. ну такое. В принципе это не проблема для подможества, где использование LATERAL это норма.
В четвертых, у вас появляется единая точка отказа, думаю тут комментировать не надо. Мы надеемся что с client_document_list будет все хорошо.. надежда плохой попутчик там где должна быть уверенность.
Установка — одна команда
Только вот недавно обсуждали что использование пайплайна в командах из сомнительных источников это плохая практика, и вот опять.
Более того на больших базах их и не думали создавать. У меня сейчас в работе несколько БД.. и они никогда не видели первичных ключей, связей и тд. Просто потому что половина данных ежедневно или ежечасно перегружается с нуля из внешних систем
Если честно не совсем понял чего вам не хватало. Код стал куда более контринтуитивным, потому что часть логики потенциально спрятана от читающего запрос.
Мне кажется, что после успеха VSinder, который что ска характерно привел к покупке и закрытию сервиса, нишевость - это очевидное условие чтобы что-то выстрелило
А вот что интересно, так это улучшения по части CoreCLR. Обещает «почти моментальный запуск в Play Mode и ускорение сборки шейдеров на 90%. Если хотя бы часть из этого правда, то уже неплохо.»
Согласно их roadmap в билдах мы увидим CoreCLR еще не скоро, пока только в редакторе.
Это была фигура речи, которую не стоит понимать буквально. Смысл в том, что технология перестала быть массовой, как в годы когда у каждого утюга был свой RSS. Для современного юзера, который пассивно потребляет алгоритмическую ленту, RSS это атавизм времен динозавров. Представь, что зумеру который только что свайпал рилсы Влада Папира надо найти на сайте ссылку, скопировать ее в агрегатор.. это устаревший UX, который приветствуется только теми кто уже знаком с технологией, и хочет избежать информационного шума. Теперь RSS это очень нишевая фича.
Ну и 90-ые у меня ассоциируются с диким криминалом
Камон, автор 94 года рождения, к моменту когда он в школу пошел, от 90х остались только эхо и воспоминания. А рассказывает он так словно люди с автоматами вывезли его в багажнике в лесополосу и заставили копать яму. Скорее всего, спонсорам нужен был определенный результат, которого он не достиг и ему тупо указали на дверь
Судя по тому что персонаж юлит и последовательно избегает прямых ответов на вопросы, то вангую скорее всего со стороны кружка тоже дожны были быть определенные обязательства, достигнуты определенные результаты.. которые не были реализованы потому что "му-хрю мы детский кружок"
наблюдая за своими родственниками которые в поисковой строке яндекса пишут ВТБ чтобы перейти в онлайн банкинг на vtb.ru .. я сомневаюсь что у кого-то там что-то обломится.
Ну.. если экран совсем не убит, а к примеру разбит только тач, и замена не рентабельна, то стоит попробовать включить отладку, а дальше уже можно через adb жмакать по экрану
Вторая проблема, что если любой современный смартфон тупо включить на постоянку в сеть, то через месяц можно получить взувшеюся батарею и, если сильно не повезет, пожар
Большинство современных смартфонов имеют встроенную защиту от перезаряда, и способны работать напрямую от сети, минуя аккумулятор, что позволяет не дрочить его микроперезарядками. Пожар случается, если завернуть его в теплоизоляцию. Так почти все случаи связаны с тем, что владельцы собрали комбо) смартфон был на зарядке, работал над ресурсоемкими приложениями (игры) и был забыт под подушкой.
Если вы получаете примерно одинаковый негативный фидбек, то со статьей определенно что-то не то
Ну значит вы никогда понастоящему не работали с данными. Потому что реляции по ключам реальны только там где они существуют с первого дня, а в жизни все немного иначе. В жизни есть дубли, есть поврежденные и фрагментированные данные. Данные которые вы получаете, но не управляете. У нас основная бд с которой работает подразделение получает данные с оборудования через xml дампы и принтауты консольных команд. Каждый день потенциально новый тип у существующей колонки, и появление новых. Никаких первичных ключей или признаков уникальности не предусмотрено в принципе. Максимум этой базы - синтетические id которые корректны только от аплоада до аплоада.
Тоже самое с картографическими данными коих у нас великое множество
в целом согласен с https://habr.com/ru/articles/1065796/comments/#comment_30292374
Проблема в том, что подход из статьи только увеличивает энтропию и количество обьектов.
Что характерно нет никакого этому подтверждения, потому что похоже в статье отсутствует план запроса до-после, или какой-либо бенчмарк. У джентельменов принято верить на слово, и если в pg в все именно так, то это замечательно, но к примеру в sql server использование методов.. смерти подобно потому что код в большинстве случаев не разматывается оптимизатором, как в случае вью или сахарных CTE.
Лично мое мнение, как человека который последние 10 лет только и делает, что пялится в SQL.. за такое надо немного бить, может быть даже палкой. Во первых за то что это здорово снижает читаемость и понимание кода. Я абсолютно уверен, что пять одинаковых ON не многословность, а явное намерение.
Во вторых, за нейминг в приведенном примере. Табличные и скалярные методы опять же должны выражать намерение в названии.. а тут его нет. В третьих..
.. я не большой специалист в Pg, но это выглядит так словно мы одной нагой залезли в N+1 проблему. Делать это преимуществом по сравнению с JOIN.. ну такое. В принципе это не проблема для подможества, где использование LATERAL это норма.
В четвертых, у вас появляется единая точка отказа, думаю тут комментировать не надо. Мы надеемся что с
client_document_listбудет все хорошо.. надежда плохой попутчик там где должна быть уверенность.Только вот недавно обсуждали что использование пайплайна в командах из сомнительных источников это плохая практика, и вот опять.
Более того на больших базах их и не думали создавать. У меня сейчас в работе несколько БД.. и они никогда не видели первичных ключей, связей и тд. Просто потому что половина данных ежедневно или ежечасно перегружается с нуля из внешних систем
Если честно не совсем понял чего вам не хватало. Код стал куда более контринтуитивным, потому что часть логики потенциально спрятана от читающего запрос.
По моему лучше немного переплатить и взять бюджетную механику,
например такую
shark attak x87, такой же трехрежимный кусочек говнеца, но он хотябы кастомизируемый и ремонтопригодный
чем мембранную
Мне кажется, что после успеха VSinder, который что ска характерно привел к покупке и закрытию сервиса, нишевость - это очевидное условие чтобы что-то выстрелило
Это и было массовое применение :D
Согласно их roadmap в билдах мы увидим CoreCLR еще не скоро, пока только в редакторе.
Это была фигура речи, которую не стоит понимать буквально. Смысл в том, что технология перестала быть массовой, как в годы когда у каждого утюга был свой RSS. Для современного юзера, который пассивно потребляет алгоритмическую ленту, RSS это атавизм времен динозавров. Представь, что зумеру который только что свайпал рилсы Влада Папира надо найти на сайте ссылку, скопировать ее в агрегатор.. это устаревший UX, который приветствуется только теми кто уже знаком с технологией, и хочет избежать информационного шума. Теперь RSS это очень нишевая фича.
В этом случае обычно молчат в целом, а не пишут таинственную статью )
Камон, автор 94 года рождения, к моменту когда он в школу пошел, от 90х остались только эхо и воспоминания. А рассказывает он так словно люди с автоматами вывезли его в багажнике в лесополосу и заставили копать яму. Скорее всего, спонсорам нужен был определенный результат, которого он не достиг и ему тупо указали на дверь
Судя по тому что персонаж юлит и последовательно избегает прямых ответов на вопросы, то вангую скорее всего со стороны кружка тоже дожны были быть определенные обязательства, достигнуты определенные результаты.. которые не были реализованы потому что "му-хрю мы детский кружок"
RSS тихо помер потому что он не показывает контекстную рекламу, а не потому что гугел нальет. Тогда ИИ проблемы 2000 еще не было.
наблюдая за своими родственниками которые в поисковой строке яндекса пишут ВТБ чтобы перейти в онлайн банкинг на vtb.ru .. я сомневаюсь что у кого-то там что-то обломится.
например как в нашей переговорной - отвернутые к стене
Ну.. если экран совсем не убит, а к примеру разбит только тач, и замена не рентабельна, то стоит попробовать включить отладку, а дальше уже можно через adb жмакать по экрану
Большинство современных смартфонов имеют встроенную защиту от перезаряда, и способны работать напрямую от сети, минуя аккумулятор, что позволяет не дрочить его микроперезарядками. Пожар случается, если завернуть его в теплоизоляцию. Так почти все случаи связаны с тем, что владельцы собрали комбо) смартфон был на зарядке, работал над ресурсоемкими приложениями (игры) и был забыт под подушкой.
Чтобы протестировать что-то.. что не предполагает продолжительный, но слишком большой аптайм, то почему бы и нет. Все в виртуалку не засунешь.