По моим наблюдениям история на собесах как с задачей о люках. Спрашивают потому что так спрашивает и Гугл. Культ Карго. Как это соотносится с практикой на конкретной позиции задумываются не очень сильно. А стоило бы. Ведь на сколько я знаю Гугл и сам на своей статистике признал, что хорошое прохождение алгосов не даёт в итоге хорошего инженера в работе. И задачки а-ля люки убрали.
А отказ от логической по причине скорости? Видимо используется физическая, но каким образом делается обновление серверов, ведь там нужно соблюдать полное совпадение версий РСУБД? Я понимаю когда проект небольшой и серверов несколько штук всего, можно побыстрому стопнуть. Но когда их очень много? Какой путь был выбран? Предположу, что какую-то логику пришлось заложить в PgBouncer.
А как это влияет на способ хранения КВС? Джоиним по FK, расставляем ключи. Профит. Не тестил, но не вижу ни каких специфичных проблем которые появятся именно из-за range. Все укладывается в обычные истории с большими таблицами и их связями с другими таблицами. Опять же, тестовый стенд с данными есть в docker. При желании можно нагенерить туда случайных юзеров и проверить что в итоге будет.
Хочу обратить внимание на упомянутую статьи 208. Но другой пункт. Конкретно п. 1.6:
вознаграждение за выполнение трудовых или иных обязанностей, выполненную работу, оказанную услугу, совершение действия в Российской Федерации.
Что есть "совершенное действие"? Человек с ноутбука через терминальный доступ работает на сервере находящийся в РФ. Код уходит на сервер в РФ. Вся цепочка, кроме нажатия клавиш происходит в РФ. Итог работы также остается в РФ. Можно предположить, что такие в итоге это действия в РФ в целом.
Особенно если дочитать эти пункты до конца. А там:
рассматриваются как доходы, полученные от источников в Российской Федерации, независимо от места, где фактически исполнялись возложенные на этих лиц управленческие обязанности или откуда производились выплаты указанных вознаграждений
Т.е. тут явно указывается, что не имеет значения где физически находился человек. Да, тут приведена конкретная группа лиц и это не IT. Но сама логика пунктов готовит о том, что физическое нахождение не принципиально.
В итоге на мой взгляд мы имеем юридическую неопределенность которую еще предстоит разрешить. В и зависимости от принятого решения сможет вполне оказаться, что возникнет недоимка по НДФЛ.
Для КВС практического смысла нет. Я не зря нашел ограничение сверху и ввел его в ТЗ. Количество данных получилось ограниченное и небольшой, поэтому даже без индексов это работало бы быстро.
Но при желании можно наполнить базу и милионами записей. Для этого я и завел эти схемы в docker. Любой читатель может себе склонировать, запустить и поиграться с идексами и количеством данных. Все sql для этого есть в репозитории.
В общем я сделал вариант и с box. К сожалению в настоящее время Хабр пока не дает отредактировать статью и добавить туда этот вариант. Но данная заметка есть в формате видео. Если интересно, оно публичное. Ссылка на схему D: https://www.youtube.com/watch?v=LOtEC68d1Aw&t=725s
Оччень интересный вариант. Т.е. у нас будет 2ое поле в котором прямоугольники не могут пересекаться и даже соприкасаться. Т.е. у нас все сведется к 2 полям в таблице: age_and_experience box и value number. Обязательно попробую и этот вариант. Спасибо за идею!
Предложенный вариант с 1 таблицей тоже не помешает вставить повторяющиеся диапазоны, т.к. на уровне РСУБД это будут int + уникальный индекс. Но он позволит создать диапазон 22-22 при существовании диапазона 16-24.
В этом и суть отдельного типа данных range. Кроме цифр (границ диапазона) PostgreSQL еще и знает, что это диапазоны и может контролировать консистентность данных из коробки. Плюс он дает над ними еще и арифметику (которая будет полезна при составлении расписаний).
По сравнению с вариантом 3 таблиц не только. Тут есть контроль целостности, а так же богатый список операторов на пересечения, свободность и прочее. На КСВ может это не так очевидно. Система бронирования в отелях может быть более показательна, но я хотел делать слишком сложный пример.
А есть российские провайдеры с которым можно работать через Outline? В DO все без проблем поднимается одной кнопкой, но в приложении я не вижу провайдеров из РФ. Может кто знает?
Производительность. Если делать это через сам сервис, то нужно зайти в профиль, посмотреть данные которые при этом могут оказаться еще не нормализованными. Это просто ацки медленно получается потому как это ручной труд.
Готовая же база с кандидатами позволяет находить нужные профили кандидатов просто на основании выборки из базы. В самом примитивном виде это обычная эксель таблица с фильтрами, в самом навороченном это внутренняя система HR агентства в которую стекаются в нормализованном виде все необходимые данные.
Не согласен с переводом "An HTML Response" как "HTML-отклик". В индустрии сложившийся практика именования коммуникации между сервером и клиентом это: запрос <-> ответ. Но ни как не "отклик". Очень уже режет глаза.
По моим наблюдениям история на собесах как с задачей о люках. Спрашивают потому что так спрашивает и Гугл. Культ Карго. Как это соотносится с практикой на конкретной позиции задумываются не очень сильно. А стоило бы. Ведь на сколько я знаю Гугл и сам на своей статистике признал, что хорошое прохождение алгосов не даёт в итоге хорошего инженера в работе. И задачки а-ля люки убрали.
А отказ от логической по причине скорости? Видимо используется физическая, но каким образом делается обновление серверов, ведь там нужно соблюдать полное совпадение версий РСУБД? Я понимаю когда проект небольшой и серверов несколько штук всего, можно побыстрому стопнуть. Но когда их очень много? Какой путь был выбран? Предположу, что какую-то логику пришлось заложить в PgBouncer.
В pgq-очередь это случайно не на listen/notify ли строится?
Много ли денег хотят за доступ или прямо реально подлючиться условному разрабу для аналитики?
Хм... Т.е. джоиним 100500 юзеров с таблицей КВС? Не очень уловил, что делаем и что хотим получить.
Продолжение истории с 4 вариантом - box, читайте в этой заметке: Сохраняем диапазон в виде box типа
А как это влияет на способ хранения КВС? Джоиним по FK, расставляем ключи. Профит. Не тестил, но не вижу ни каких специфичных проблем которые появятся именно из-за range. Все укладывается в обычные истории с большими таблицами и их связями с другими таблицами. Опять же, тестовый стенд с данными есть в docker. При желании можно нагенерить туда случайных юзеров и проверить что в итоге будет.
Хочу обратить внимание на упомянутую статьи 208. Но другой пункт. Конкретно п. 1.6:
Что есть "совершенное действие"? Человек с ноутбука через терминальный доступ работает на сервере находящийся в РФ. Код уходит на сервер в РФ. Вся цепочка, кроме нажатия клавиш происходит в РФ. Итог работы также остается в РФ. Можно предположить, что такие в итоге это действия в РФ в целом.
Особенно если дочитать эти пункты до конца. А там:
Т.е. тут явно указывается, что не имеет значения где физически находился человек. Да, тут приведена конкретная группа лиц и это не IT. Но сама логика пунктов готовит о том, что физическое нахождение не принципиально.
В итоге на мой взгляд мы имеем юридическую неопределенность которую еще предстоит разрешить. В и зависимости от принятого решения сможет вполне оказаться, что возникнет недоимка по НДФЛ.
Для КВС практического смысла нет. Я не зря нашел ограничение сверху и ввел его в ТЗ. Количество данных получилось ограниченное и небольшой, поэтому даже без индексов это работало бы быстро.
Но при желании можно наполнить базу и милионами записей. Для этого я и завел эти схемы в docker. Любой читатель может себе склонировать, запустить и поиграться с идексами и количеством данных. Все sql для этого есть в репозитории.
Ну я в секции ответов про это рассказал. Там да, были вопросы про производительность.
В общем я сделал вариант и с box. К сожалению в настоящее время Хабр пока не дает отредактировать статью и добавить туда этот вариант. Но данная заметка есть в формате видео. Если интересно, оно публичное. Ссылка на схему D: https://www.youtube.com/watch?v=LOtEC68d1Aw&t=725s
Это если частный дом. А если квартира (а МКД бывают даже в районных центрах на 10-50к жителей), то бензогенератор не подходит.
Оччень интересный вариант. Т.е. у нас будет 2ое поле в котором прямоугольники не могут пересекаться и даже соприкасаться. Т.е. у нас все сведется к 2 полям в таблице:
age_and_experience box и value number. Обязательно попробую и этот вариант. Спасибо за идею!А можно немного идею раскрыть? Какая схема БД при этом получается?
Предложенный вариант с 1 таблицей тоже не помешает вставить повторяющиеся диапазоны, т.к. на уровне РСУБД это будут int + уникальный индекс. Но он позволит создать диапазон 22-22 при существовании диапазона 16-24.
В этом и суть отдельного типа данных range. Кроме цифр (границ диапазона) PostgreSQL еще и знает, что это диапазоны и может контролировать консистентность данных из коробки. Плюс он дает над ними еще и арифметику (которая будет полезна при составлении расписаний).
Нормализации с разнесением по 3 таблицам? С ходу в голову приходит только такой вариант.
По сравнению с вариантом 3 таблиц не только. Тут есть контроль целостности, а так же богатый список операторов на пересечения, свободность и прочее. На КСВ может это не так очевидно. Система бронирования в отелях может быть более показательна, но я хотел делать слишком сложный пример.
А есть российские провайдеры с которым можно работать через Outline? В DO все без проблем поднимается одной кнопкой, но в приложении я не вижу провайдеров из РФ. Может кто знает?
Производительность. Если делать это через сам сервис, то нужно зайти в профиль, посмотреть данные которые при этом могут оказаться еще не нормализованными. Это просто ацки медленно получается потому как это ручной труд.
Готовая же база с кандидатами позволяет находить нужные профили кандидатов просто на основании выборки из базы. В самом примитивном виде это обычная эксель таблица с фильтрами, в самом навороченном это внутренняя система HR агентства в которую стекаются в нормализованном виде все необходимые данные.
Не согласен с переводом "An HTML Response" как "HTML-отклик". В индустрии сложившийся практика именования коммуникации между сервером и клиентом это: запрос <-> ответ. Но ни как не "отклик". Очень уже режет глаза.