А откуда он это знает? Где зафиксирован этот контракт?
Так ведь вы его, как разработчик базы, сами и создаёте!
И предполагается, что создаёте вы его таким, чтобы он позволял всё нужное и не позволял всё ненужное.
Вы же спрашиваете, что будет, если вы, единственный создатель и властитель контракта, его же будете нарушать.
Разумеется, ничего хорошего не будет, но так предположение в том и состоит, что вы, единственный, кто имеет техническую возможность нарушить свой собственный контракт, как раз и не станете этого делать. Иначе это осознанное стреляние в ногу.
Вам как разработчику базы — совершенно ничего. Как разработчик базы, вы имеете к ней полный доступ на фазе разработки, и предполагается, что вы используете его во благо.
Точно так же ничего не мешает локальному администратору отформатировать диск без бекапа. Он просто не должен этого делать, потому что это неправильно, и предполагается, что он и не станет.
Все остальные не могут создать в БД процедуру, которая обновит статус документа.
Это всё равно, что спросить — а что, если предприимчивый девелопер найдёт в vTable вашего класса указатель на private-метод и вызовет его напрямую, в обход публичного интерфейса вашего класса?
Разумеется, в этом случае всё сломается, но так и должно быть.
У разработчика этой базы данных есть возможность поступить так. Он не должен так делать, но если сделает, то это оннарушил контракт.
А у разработчика клиента к этой базе такой возможности быть не должно.
В контексте базы данных это решается выдачей нужных разрешений и невыдачей ненужных.
Всё это, разумеется, применимо к ситуации, когда база содержит логику, а не является безмозглым хранилищем для среднего слоя.
Вы создаёте базу и её объекты от имени dbo. От его же имени выдаёте нужным ролям нужные разрешения на эти объекты.
А когда вы разрабатываете клиент к этой базе, использующий созданные объекты базы, вы делаете это с connection string, соответствующей роли пользователя.
Если клиент имеет админский доступ, значит вы либо используете подход code-first (когда база создаётся из клиента), либо что-то делаете неправильно. Локальность базы ничего не меняет в этом смысле.
Статья называется "Вред хранимых процедур", и я воспринял её в общем, архитектурном контексте, а историю реализации именно на PostgreSql — как повод к дискуссии, а не установление границ обсуждения.
Прошу прощения, если разговор должен был быть именно про хранимые процедуры PostgreSql.
В большинстве случаев updlock. updlock, rowlock, readpast для таблиц с элементами на обработку первым освободившимся воркером. updlock, paglock, holdlock для исключения возможности появления новых записей, удовлетворяющих некоему where, за период обработки старых (оптимально работает при наличии индекса, покрывающего where — ставит лок на соответствующую его страницу; иначе может заблокировать всю таблицу).
Иногда xlock.
Очень редко, по крайней необходимости, tablock, xlock.
Эффект от хинтов в деле предотвращения дедлоков косвенный; количество дедлоков уменьшается за счёт того, что некоторые чтения, которые были бы иначе успешны и в конце могли привести к дедлоку, превращаются в обычные ожидания до того, как дедлок мог бы произойти. Основной эффект от хинтов — максимально возможная конкурентность при гарантии исключения случайной двойной обработки данных разными клиентами.
как именно вы обращаетесь к данным в одном порядке, если речь о распределенной системе
Порядок обращения имеет смысл в рамках одной транзакции.
Если одна транзакция считывает сначала фрукты, потом овощи, а другая — овощи, потом фрукты, то вероятность дедлока между ними выше, чем если обе считывают сначала овощи, потом фрукты, или наоборот.
Если одна транзакция заинтересована только в овощах, а вторая только во фруктах, порядок их запуска не имеет значения.
Вынесение этой логики в базу позволяет легко унифицировать этот порядок для всех клиентов и легко его поменять, если когда оптимизатор запросов решит, что данных в таблицах набралось достаточно много, чтобы перестроить планы запросов.
Полностью избежать дедлоков нельзя. Их можно сильно уменьшить, если обращаться к данным в одном порядке и использовать updlock для тех данных, которые в итоге предполагается обновить.
Использовать один и тот же порядок доступа к данным можно и из ORM, но там а) нет хинтов, и б) если вдруг запрос странслируется недостаточно оптимально, можно получить эскалацию блокировки. Например, при запросе множества "1 родитель + его дети" ORM, чтобы избежать ситуации n+1, может запросить всю структуру одним запросом, но с вложенным (select count(*)) для собственного удобства парсинга результата, что плохо для блокировки. Или таки скатывается в n+1, что тоже не фонтан.
Пессимистичность блокировок — гарантия успеха в смысле их противопоставления оптимистичным блокировкам. ORM в основном работают по оптимистичным блокировкам — при чтении из базы ничего не блокируется, а при последующем обновлении обновление выполняется только если соответствующие поля не были изменены с момента запроса (т.е. к условию update .. where id = 42 автоматически дописывается and field1 = 'asd' and field2 is null). Если значения полей оказываются иные, база возвращает "0 rows affected", и ORM транслирует это в исключение "Оптимизм не оправдался, обновите свою картину мира и попробуйте снова". Механизм проверки, конечно, можно отключить, но это отложенное стреляние в ногу.
Разумеется, всё это верно для областей, где, собственно, важно быть уверенным, что обновление вносится именно в ту версию объекта, которая была прочитана из базы (складской учёт, денежные транзакции). В других областях может быть совершенно безвредно переписать объект его новейшей версией безотносительно оригинального состояния (редактирование постов на форуме).
Удобный полный доступ ко всем функциям используемого диалекта SQL, а не только к общему подмножеству, используемому ORM-фреймворком.
Как результат — возрастающее желание, которому трудно сопротивляться, перетащить в базу ещё больше логики, потому что очень изящно всё с sum() over(partition by) получается.
Возможность тонкой настройки конкурентности и избежания дедлоков, хинтами и перестановкой операторов.
Как результат — все блокировки пессимистичные (гарантия успеха финального update), и при этом никто никому не мешает.
Избежание ORM-сгенерированных запросов, которые выполняются ужасно долго, хотя если переписать вручную чуть иначе — мгновенно.
Возможность быстрого написания тонких клиентов на любых фреймворках к этой базе-приложению. Одновременно нескольких, для клиентов из разных областей — один на ASP.NET MVC Core, один в MS Excel, один в MS Access, один на powershell. При правильной инкапсуляции изменение функционала базы-приложения часто не требует никаких изменений в этом зоопарке клиентов вообще.
Моментом получения дохода считается момент поступления средств на ваш банковский счёт. Средства, которые вам должны выплатить ("пишется только сколько можно вывести"), но ещё не выплатили, пока не учитываются.
Во всех случаях базой для исчисления налога является ваш доход до вычета любых агентских комиссий, связанных с его получением (комиссия ютуба, айстора, платёжных систем).
Видимо, зависит от организации внутренних процедур банка.
Как агент валютного контроля, банк обязан ставить договор на учёт, если сумма операций с отдельным контрагентом превысит 6 млн рублей (не в год, а вообще).
Мой банк просит договоры сдавать сразу. При отправке инвойса на валютный контроль каждый раз требуют ссылаться на соответствующий договор. Ссылаюсь.
Возможно, в вашем банке процедура больше оптимизирована под клиента, и договор попросят, только когда приблизитесь к 6 млн.
Иностранная компания работает по законам своей юрисдикции.
Если в их юрисдикции понятие "ИП" отсутствует (что не редкость), то сам вопрос, "обычный" физик вы или не совсем, для них не имеет юридического смысла. Все физики для них "обычные".
Заключить нетрудовой договор с "обычным" самозанятым физиком (самозанятым, опять же, в общечеловеческом смысле, а не в юридической формулировке, имеющей действие только в России) на оказание разовых услуг они, скорее всего, имеют полное право по правилам, опять же, своей юрисдикции. Для них это будут отношения B2B, и в договоре будет обязательно прописано, что отношения не являются трудовыми, и что ответственность за надлежащую уплату своих налогов вы несёте сами.
Для всего этого work permit не нужен.
Безусловно, в общем случае всё зависит от характера работ и регулярности получения дохода. Но жёстких критериев нет.
Если вы ежемесячно закупаете сырьё и изготавливаете продукцию, доказать предпринимательскую деятельность не составит труда.
Если вы писатель и пишете две книги в год, получая гонорар в издательстве за каждую, имеете полное право просто платить НДФЛ.
Поэтому, если вы айтишник-одиночка, и у вас небольшое количество одновременных проектов (независимо от их цены), над которыми вы работаете дома на своём стареньком ноуте, то, мне кажется, доказать принципиальное отличие вас от этого писателя будет непросто. Собственно, компьютерная программа есть не что иное, как литературное произведение, просто не на русском языке...
Налоговая должна быть уверена, что именно эти присланные деньги подпадают под один из ваших патентов (у вас их может быть несколько). При работе с иностранными заказчиками для этого нужно заключить договор по месту получения патента.
Если место заключения договора в договоре не указано, можно попытаться доказать, что при отсутствии такового его следует считать по месту прописки ИП. Если не получится и это, придётся заплатить ваш обычный налог с этих сумм, поскольку они не подпадают под патент.
Возможно, вы правы. Инструкция 181-И оставляет некоторый простор для толкования.
Настоящая Инструкция распространяется на резидентов, являющихся юридическими лицами (за исключением кредитных организаций и государственной корпорации "Банк развития и внешнеэкономической деятельности (Внешэкономбанк)"), физическими лицами, являющимися индивидуальными предпринимателями или лицами, занимающимися в установленном законодательством Российской Федерации порядке частной практикой (далее при совместном упоминании — резиденты).
Настоящая Инструкция распространяется на физических лиц — резидентов при осуществлении ими валютных операций в иностранной валюте и (или) валюте Российской Федерации, связанных с предоставлением нерезидентам займов и возвратом от нерезидентов таких займов, с использованием своих банковских счетов (вкладов) (далее — физическое лицо — резидент).
Казалось бы, "чистые" физики подпадают только при работе с займами, а в остальном — только если занимаются "частной практикой" в установленном порядке. Как я понимаю, "частная практика" — это специальный термин, описывающий врачей, адвокатов, нотариусов и т.п., и не синоним ИП или самозанятости, но кто знает.
Самозанятые не могут попасть в эту ситуацию (больше 5 млн в год).
Для самозанятости лимит в 2.4 млн в год. Если доход больше, самозанятость нельзя применять.
все 20% платил бы добровольно
Тогда можно ничего не регистрировать, а просто платить НДФЛ 13%. Бонус — отсутствие валютного контроля (физлица не являются его субъектами).
Да, это так :(
Помогают:
Стопроцентного решения нет.
Так ведь вы его, как разработчик базы, сами и создаёте!
И предполагается, что создаёте вы его таким, чтобы он позволял всё нужное и не позволял всё ненужное.
Вы же спрашиваете, что будет, если вы, единственный создатель и властитель контракта, его же будете нарушать.
Разумеется, ничего хорошего не будет, но так предположение в том и состоит, что вы, единственный, кто имеет техническую возможность нарушить свой собственный контракт, как раз и не станете этого делать. Иначе это осознанное стреляние в ногу.
Вам как разработчику базы — совершенно ничего. Как разработчик базы, вы имеете к ней полный доступ на фазе разработки, и предполагается, что вы используете его во благо.
Точно так же ничего не мешает локальному администратору отформатировать диск без бекапа. Он просто не должен этого делать, потому что это неправильно, и предполагается, что он и не станет.
Все остальные не могут создать в БД процедуру, которая обновит статус документа.
Это всё равно, что спросить — а что, если предприимчивый девелопер найдёт в vTable вашего класса указатель на private-метод и вызовет его напрямую, в обход публичного интерфейса вашего класса?
Разумеется, в этом случае всё сломается, но так и должно быть.
У разработчика этой базы данных есть возможность поступить так. Он не должен так делать, но если сделает, то это он нарушил контракт.
А у разработчика клиента к этой базе такой возможности быть не должно.
В контексте базы данных это решается выдачей нужных разрешений и невыдачей ненужных.
Всё это, разумеется, применимо к ситуации, когда база содержит логику, а не является безмозглым хранилищем для среднего слоя.
Вы создаёте базу и её объекты от имени dbo. От его же имени выдаёте нужным ролям нужные разрешения на эти объекты.
А когда вы разрабатываете клиент к этой базе, использующий созданные объекты базы, вы делаете это с connection string, соответствующей роли пользователя.
Если клиент имеет админский доступ, значит вы либо используете подход code-first (когда база создаётся из клиента), либо что-то делаете неправильно. Локальность базы ничего не меняет в этом смысле.
Так и есть.
Статья называется "Вред хранимых процедур", и я воспринял её в общем, архитектурном контексте, а историю реализации именно на PostgreSql — как повод к дискуссии, а не установление границ обсуждения.
Прошу прощения, если разговор должен был быть именно про хранимые процедуры PostgreSql.
Да.
Но, действительно, можно понять по-разному.
Полная версия:
Все блокировки пессимистичные, но, благодаря наложению блокировок минимально необходимым образом:
скорее всегоможно надеяться, без дедлоков.В большинстве случаев
updlock.updlock, rowlock, readpastдля таблиц с элементами на обработку первым освободившимся воркером.updlock, paglock, holdlockдля исключения возможности появления новых записей, удовлетворяющих некоемуwhere, за период обработки старых (оптимально работает при наличии индекса, покрывающегоwhere— ставит лок на соответствующую его страницу; иначе может заблокировать всю таблицу).Иногда
xlock.Очень редко, по крайней необходимости,
tablock, xlock.Эффект от хинтов в деле предотвращения дедлоков косвенный; количество дедлоков уменьшается за счёт того, что некоторые чтения, которые были бы иначе успешны и в конце могли привести к дедлоку, превращаются в обычные ожидания до того, как дедлок мог бы произойти. Основной эффект от хинтов — максимально возможная конкурентность при гарантии исключения случайной двойной обработки данных разными клиентами.
Порядок обращения имеет смысл в рамках одной транзакции.
Если одна транзакция считывает сначала фрукты, потом овощи, а другая — овощи, потом фрукты, то вероятность дедлока между ними выше, чем если обе считывают сначала овощи, потом фрукты, или наоборот.
Если одна транзакция заинтересована только в овощах, а вторая только во фруктах, порядок их запуска не имеет значения.
Вынесение этой логики в базу позволяет легко унифицировать этот порядок для всех клиентов и легко его поменять,
есликогда оптимизатор запросов решит, что данных в таблицах набралось достаточно много, чтобы перестроить планы запросов.Полностью избежать дедлоков нельзя. Их можно сильно уменьшить, если обращаться к данным в одном порядке и использовать updlock для тех данных, которые в итоге предполагается обновить.
Использовать один и тот же порядок доступа к данным можно и из ORM, но там а) нет хинтов, и б) если вдруг запрос странслируется недостаточно оптимально, можно получить эскалацию блокировки. Например, при запросе множества "1 родитель + его дети" ORM, чтобы избежать
ситуации n+1, может запросить всю структуру одним запросом, но с вложенным(select count(*))для собственного удобства парсинга результата, что плохо для блокировки. Или таки скатывается вn+1, что тоже не фонтан.Пессимистичность блокировок — гарантия успеха в смысле их противопоставления оптимистичным блокировкам. ORM в основном работают по оптимистичным блокировкам — при чтении из базы ничего не блокируется, а при последующем обновлении обновление выполняется только если соответствующие поля не были изменены с момента запроса (т.е. к условию
update .. where id = 42автоматически дописываетсяand field1 = 'asd' and field2 is null). Если значения полей оказываются иные, база возвращает "0 rows affected", и ORM транслирует это в исключение "Оптимизм не оправдался, обновите свою картину мира и попробуйте снова". Механизм проверки, конечно, можно отключить, но это отложенное стреляние в ногу.Разумеется, всё это верно для областей, где, собственно, важно быть уверенным, что обновление вносится именно в ту версию объекта, которая была прочитана из базы (складской учёт, денежные транзакции). В других областях может быть совершенно безвредно переписать объект его новейшей версией безотносительно оригинального состояния (редактирование постов на форуме).
В хранимках чистый SQL.
Если хранимок нет, либо все запросы генерируются снаружи вручную как чистый SQL (что неудобно), либо используется ORM.
О плюсах.
Удобный полный доступ ко всем функциям используемого диалекта SQL, а не только к общему подмножеству, используемому ORM-фреймворком.
Как результат — возрастающее желание, которому трудно сопротивляться, перетащить в базу ещё больше логики, потому что очень изящно всё с
sum() over(partition by)получается.Возможность тонкой настройки конкурентности и избежания дедлоков, хинтами и перестановкой операторов.
Как результат — все блокировки пессимистичные (гарантия успеха финального update), и при этом никто никому не мешает.
Избежание ORM-сгенерированных запросов, которые выполняются ужасно долго, хотя если переписать вручную чуть иначе — мгновенно.
Возможность быстрого написания тонких клиентов на любых фреймворках к этой базе-приложению. Одновременно нескольких, для клиентов из разных областей — один на ASP.NET MVC Core, один в MS Excel, один в MS Access, один на powershell. При правильной инкапсуляции изменение функционала базы-приложения часто не требует никаких изменений в этом зоопарке клиентов вообще.
Да, версионирование там позволяет делать вещи.
https://habr.com/ru/post/489514/
Моментом получения дохода считается момент поступления средств на ваш банковский счёт. Средства, которые вам должны выплатить ("пишется только сколько можно вывести"), но ещё не выплатили, пока не учитываются.
Во всех случаях базой для исчисления налога является ваш доход до вычета любых агентских комиссий, связанных с его получением (комиссия ютуба, айстора, платёжных систем).
Имеется в виду удалённая работа, конечно.
Если бы её было нельзя, всяких фриланс точка ком не было бы, но они есть.
Видимо, зависит от организации внутренних процедур банка.
Как агент валютного контроля, банк обязан ставить договор на учёт, если сумма операций с отдельным контрагентом превысит 6 млн рублей (не в год, а вообще).
Мой банк просит договоры сдавать сразу. При отправке инвойса на валютный контроль каждый раз требуют ссылаться на соответствующий договор. Ссылаюсь.
Возможно, в вашем банке процедура больше оптимизирована под клиента, и договор попросят, только когда приблизитесь к 6 млн.
Иностранная компания работает по законам своей юрисдикции.
Если в их юрисдикции понятие "ИП" отсутствует (что не редкость), то сам вопрос, "обычный" физик вы или не совсем, для них не имеет юридического смысла. Все физики для них "обычные".
Заключить нетрудовой договор с "обычным" самозанятым физиком (самозанятым, опять же, в общечеловеческом смысле, а не в юридической формулировке, имеющей действие только в России) на оказание разовых услуг они, скорее всего, имеют полное право по правилам, опять же, своей юрисдикции. Для них это будут отношения B2B, и в договоре будет обязательно прописано, что отношения не являются трудовыми, и что ответственность за надлежащую уплату своих налогов вы несёте сами.
Для всего этого work permit не нужен.
Безусловно, в общем случае всё зависит от характера работ и регулярности получения дохода. Но жёстких критериев нет.
Если вы ежемесячно закупаете сырьё и изготавливаете продукцию, доказать предпринимательскую деятельность не составит труда.
Если вы писатель и пишете две книги в год, получая гонорар в издательстве за каждую, имеете полное право просто платить НДФЛ.
Поэтому, если вы айтишник-одиночка, и у вас небольшое количество одновременных проектов (независимо от их цены), над которыми вы работаете дома на своём
старенькомноуте, то, мне кажется, доказать принципиальное отличие вас от этого писателя будет непросто. Собственно, компьютерная программа есть не что иное, как литературное произведение, просто не на русском языке...Налоговая должна быть уверена, что именно эти присланные деньги подпадают под один из ваших патентов (у вас их может быть несколько). При работе с иностранными заказчиками для этого нужно заключить договор по месту получения патента.
Если место заключения договора в договоре не указано, можно попытаться доказать, что при отсутствии такового его следует считать по месту прописки ИП. Если не получится и это, придётся заплатить ваш обычный налог с этих сумм, поскольку они не подпадают под патент.
Возможно, вы правы. Инструкция 181-И оставляет некоторый простор для толкования.
Казалось бы, "чистые" физики подпадают только при работе с займами, а в остальном — только если занимаются "частной практикой" в установленном порядке. Как я понимаю, "частная практика" — это специальный термин, описывающий врачей, адвокатов, нотариусов и т.п., и не синоним ИП или самозанятости, но кто знает.
Самозанятые не могут попасть в эту ситуацию (больше 5 млн в год).
Для самозанятости лимит в 2.4 млн в год. Если доход больше, самозанятость нельзя применять.
Тогда можно ничего не регистрировать, а просто платить НДФЛ 13%. Бонус — отсутствие валютного контроля (физлица не являются его субъектами).