Что такое УИП в платёжных квитанциях Сбербанка Онлайн. Реальный (UID) и эффективный (EUID) идентификаторы пользователя Что такое uid пользователя

Содержание

Как и во многих кредитных организациях, от плательщиков Сбербанка в ряде документов требуется указывать уникальный идентификатор. В связи с этим многие при платежах в садик или оплате штрафов в ГИБДД озадачиваются, что такое УИН в Сбербанк онлайн, что за номер следует обозначить в квитанции? Это следует узнать до осуществления перевода, так как при ошибке сумма при возврате не зачислится на ваш счет.

Что такое УИН при оплате в Сбербанк Онлайн

Понятие был введено МинФином с 4 февраля 2014 года как уникальный идентификатор начислений для правильного определения бюджетных поступлений и для упрощения системы начислений. При осуществлении перевода в бюджетные органы услугой Сбербанк Онлайн, например, штрафа по постановлению, сервис предполагает обязательное заполнение кода отдельным полем, без заполнения которого платеж не может быть проведен банком. Пояснить, что такое УИН в Сбербанк Онлайн, поможет сама кредитная организация консультацией на горячей линии.

Значение идентификатора начисления

Согласно новым правилам оформления платежных поручений с 04.02.2014 года для перечислений в российский бюджет был введен реквизит «уникальный идентификатор начисления», который выглядит как 20 значная последовательность цифр, оканчивающаяся символами «///». Идентификатор обязателен к указанию в поле «Код» платежного документа при совершении оплаты в бюджетную систему, чтобы обеспечить соответствие начислений фактической оплате. За счет уникального номера информация отражается у органа, начисляющего платеж, и у получателя с фиксацией конкретного перевода.

Каждая цифровая позиция кода имеет значение и определенную расшифровку:

• три первых – код распорядителя (так, для налоговой это 182, ГИБДД – 188);
• четвертая цифра – организация, принимающая платеж;
• остальные позиции – назначение перевода с указанием прочих необходимых конкретных сведений для его идентификации.

Для чего нужен код УИН

Уникальный идентификатор платежа формируется бюджетным учреждением самостоятельно. Он необходим для осуществления корректного учета каждого перевода в бюджетный орган государства, среди которых: налоговые, таможенные органы, дошкольные детские учреждения и пр. Что такое УИН в Сбербанк Онлайн при таком случае – это индекс документа, требуемый для указания при оплате:

• обязательных налогов, госпошлин, сборов, администрируемых налоговыми органами;
• штрафов по постановлениям государственных органов;
• услуг муниципальных и государственных заведений.

Уникальный идентификатор начисления в платежном поручении

При формировании платежного документа код требуется обозначить в начале поля «Назначение платежа» словом «УИН» и далее без пробелов само значение идентификатора, состоящего из 20 знаков, то есть указывается 23 символа вместе с ключевым словом реквизита. При необходимости указания другой информации процедура проводится с помощью тройного слеша. Любая кредитная организация предоставляет образцы заполнения документов с применением идентификатора.

УИН в квитанции

При оплате услуг за обучение ребенка или за посещение детского сада требование заполнения реквизитов идентификатора в квитанции также обязательно. Что такое УИН в квитанции – эту информацию следует узнать у бухгалтеров заведения. Банк такой номер вам не предоставит и, помимо того, без него документ, скорее всего, не примут или он вернется. Полученный один раз двадцатизначный код используется при каждом платеже, позволяет учесть средства конкретно за вашего ребенка и к вопросу, что же такое УИН в Сбербанк Онлайн для оплаты услуг детского сада или школы, уже не надо возвращаться.

Оплата по УИН налоговых платежей

По уплате налогов (транспортного, земельного, налога на имущество) уникальный номер присваивается получателем доходов – налоговой инспекцией. Если оплата налогов физическими лицами осуществляется по уведомлению, направленного самими налоговыми органами, то, как правило, к нему прилагается уже заполненный платежный документ с обязательными реквизитами.

В качестве идентификатора документа присваивается его индекс. Рекомендуется перед оплатой убедиться о наличии кода в полученном требовании налоговых служб. Если налогоплательщик планирует осуществить налоговый платеж без налогового уведомления, то документ на перечисление сумм можно сформировать самостоятельно на сайте налоговой службы, где сервисом индекс присваивается автоматически.

УИН при оплате штрафа ГИБДД

Установленный идентификатор присутствует в определенном документе, выдаваемом плательщику как подтверждение его получения от ГИБДД. УИН определяется из квитанции, где номер протокола и есть идентификатор. Все банки, принимающие такие платежи, должны при переводе обеспечить идентификацию параметров: дата вынесения постановления и его номер. Помимо этого, банк должен сформировать УИН для перевода независимо, есть ли штраф в единой базе данных казначейства, то есть, определить код могут и ГИБДД, и банковское учреждение.

Для уплаты штрафов можно через интернет посредством определенных формул рассчитать уникальный номер начислений ГИБДД (для старых штрафов до февраля 2014 г.), который будет присвоен после ввода данных:

• серия и номер постановления;
• дата постановления.

Как узнать УИН в Сбербанк Онлайн

При осуществлении через онлайн-сервисы Сбербанка бюджетных платежей для совершения перевода потребуется определить, что такое УИП в Сбербанк Онлайн. Для этого пользователю необходимо проделать следующее:

1. В личном кабинете ввести сведения о платеже.
2. Активировать поле «Информация».
3. Получить чек, где обозначен «Идентификатор плательщика» из 20 цифр.
4. В Сбербанк Онлайн при заполнении данных платежа в поле «УИН» указать из чека идентификатор плательщика.
5. Для каждого платежа следует получить свой код, проделав снова весь процесс.

Разъяснения ФНС о порядке указания идентификатора при заполнении

С целью понимания применения идентификатора и правильного указания информации ФНС РФ пояснила новый режим указания УИН в реквизитах распоряжений при переводе денежных средств для бюджетных организаций. Плательщики налогов, физические лица, платят налоги исходя из уведомления налогового органа и прилагаемого платежного извещения. На сайте ФНС с помощью электронного сервиса Росреестра доступно оформить документ на налоговую уплату самостоятельно, при этом обеспечено автоматическое присвоение УИН.

В разъяснениях сказано, что налоги можно проплатить наличными средствами через банк. При заполнении документа в отделении Сбербанка код не указываются, а платежное извещение должно содержать обязательно ИНН плательщика, полностью ФИО лица, его место жительства или адрес места пребывания. При оплате через другое кредитное учреждение оформляется полное платежное поручение с заполнением поля "Код", где указывается ноль или индекс при наличии его у физического лица.. Другой случай – оплата физлицом суммы налогов на имущество на основании уведомления от налоговой службы, где индекс документа применен как идентификатор платежа.

При расчете за медицинское обслуживание у квитанции тоже есть поле «Уникальный идентификатор», но зачастую при совершении платежей не предполагается кода для оплачиваемых медицинских услуг. Тогда необходимо проставить «0» в соответствующей графе. Медицинские заведения информацию о коде публикуют на официальных сайтах либо сведения, что такое УИН в Сбербанке Онлайн при оплате таких услуг, доступно получить в центре, где выписывалась квитанция об оказании медицинского обслуживания.

Видео

Владельцы карт «Сбербанка» предпочитают оплачивать различные услуги, квитанции и тарифы ЖКХ и налоги дистанционно, пользуясь сервисом Сбербанк Онлайн. При заполнении электронных платёжек часто попадаются пункты УИН и УИП.

Эти определения появились в платёжных извещениях сравнительно недавно, поэтому их назначение часто путают даже опытные бухгалтеры. Разберёмся, что такое УИП и УИН в квитанциях «Сбербанка» и для чего они нужны.

Рассматриваемые определения появились в 2014 году с лёгкой руки Министерства финансов Российской Федерации. По сути, это персонализаторы платежей, которые не только определяют характер и назначение платежа, но и упрощают ведение статистики госструктурами и учреждениями, в чью пользу совершается транзакция.

Поговорим о том, что означают данные аббревиатуры. Итак:

• УИН – Уникальный Идентификатор Начислений. Данный код обязателен для перевода средств бюджетным организациям, которые находятся на гособеспечении. Это может быть родительская плата за детский садик или погашение штрафа, выписанного сотрудником ГИБДД.
• УИП – Уникальный Идентификатор Платежей. Применяется для выполнения денежных переводов, направленных в государственный бюджет, например, налогов, пошлин или страховых взносов.

Разница между этими определениями заключается в том, что УИН присваивается платёжному документу получателем перевода – госорганизацией, в пользу которой делается транзакция. Код не зря называется уникальным, поэтому никогда не повторяется дважды. УИП является именно идентификатором и помогает выделить перевод среди сотен тысяч похожих платежей. Если УИП неизвестен отправителю, поле можно оставлять незаполненным или ставить 0.

Важно! В платёжных извещениях УИП и УИН ставятся в графе 22. Обратите внимание, что указывается только один идентификатор: пересекаться они не должны.

Где получить

В некоторых электронных платёжках, которые проводятся через сервисы Сбербанка Онлайн, идентификаторы определяются автоматически. Если этого не произошло, перед плательщиками возникает логичный вопрос: где взять нужную кодировку, чтобы платёж не затерялся, а был доставлен по назначению.

В плане получения УИН сложностей обычно не возникает. Эта информация указывается на квитанциях, предназначенных для оплаты. Поэтому остаётся лишь аккуратно перепечатать цифры в поле 22 электронной платёжки. Сам код представляет собой 20-значную числовую комбинацию, где:

• Первые 3 цифры – распределитель платежа, например, код налоговой службы 182, а ГИБДД – 188.
• Четвёртая цифра – код организации-получателя.
• Остальные цифры – дополнительная информация, необходимая для перевода средств.

Нужно уточнить, что УИН нельзя найти самостоятельно, воспользовавшись таблицами либо интернет-справочниками. Код уникален, поэтому присваивается каждой платёжке индивидуально.

В случае с получением УИП всё выглядит несколько сложнее. Такую кодировку необходимо получать заблаговременно, при первом оформлении документации. Выдать идентификатор могут следующие организации:

• Фонд социального страхования.
• Федеральная налоговая служба.
• Пенсионный фонд.
• Таможенная служба.

Если идентификатор платежа не получен, в графе 22 ставится 0. В этом случае банк выполнит перевод по ИНН плательщика и другим реквизитам организации-получателя, например, КБК. Если код присвоен, его вводят в обязательном порядке. Если отправитель допускает ошибку при введении цифровой комбинации, средства будут зачислены на расчётный счёт другой организации.

Добавим, что пока нет твёрдых и обязательных указаний для использования плательщиками УИН или УИП в каждом конкретном случае, поэтому электронные платёжные системы одинаково воспринимают оба идентификатора. Поэтому УИП пока не получил широкого распространения, учитывая специфику его получения: его предоставляют руководителям организаций и индивидуальным предпринимателям. Обычным гражданам пользоваться таким идентификатором нет необходимости, поэтому при оплате налогов, штрафов и услуг бюджетных организаций обычно используется УИН.

Как выглядит правильно заполненный документ

Чтобы избежать неприятных ситуаций и просрочек по внесению средств на счета получателя, каждому человеку нужно иметь представление о правильности заполнения платёжного документа. В обязательном порядке отображаются такие данные:

• Номер платёжки.
• Дата проведения транзакции.
• Формат документа: бумажный или электронный.
• Полное наименование организации и ИНН получателя.
• Сведения об отправителе.
• Общие реквизиты, необходимые для списания/зачисления средств: лицевой счёт, номер карты и прочее.
• Назначение платежа: штраф, страховой взнос, плата за образование.
• Подпись и печать (необязательно для электронных документов).

В дополнительных графах указываются суммы, расчётный период, сроки зачисления, УИП или УИН в зависимости от характера транзакции.

Оплата детского сада через Сбербанк Онлайн

Прочитав предыдущие разделы, многие налогоплательщики, которые уплачивают положенные сборы и взносы в частном порядке, могут подумать, что процедура интернет-платежей заметно усложнилась. Это не так. В большинстве случаев электронная платёжная система автоматически заполняет необходимые поля, после того, как плательщик укажет ИНН организации-получателя.

Рассмотрим, как проводится процедура оплаты детского сада с использованием кодировки УИН.

Пошаговая инструкция по проведению такого платежа будет выглядеть следующим образом:

1. Авторизация в системе. Для этого используются персональные логин и пароль пользователя, которые можно распечатать в любом банкомате или получить дистанционно, выбрав на странице входа в систему пункт «РЕГИСТРАЦИЯ».
2. Выбор нужного раздела. На главной странице выбирается основной раздел, который называется «ПЛАТЕЖИ И ПЕРЕВОДЫ», далее подкатегория «ОБРАЗОВАНИЕ». Здесь нужно выбрать дошкольное учреждение, в пользу которого осуществляется платёж.
3. Заполнение реквизитов. Здесь обязательно нужно проверить регион, который должен совпадать с областью проживания и ИНН получателя. Далее нужно указать назначение перевода, в нашем случае это – «РОДИТЕЛЬСКИЙ ПЛАТЁЖ», указывается лицевой счёт, номер карты для списания денежных средств, сумма и КБК.
4. Подтверждение. После этого остаётся лишь проверить правильность заполнения обязательных полей и подтвердить перевод при помощи кода безопасности, который высылается на номер плательщика.

Наверняка у многих возник вопрос, почему в инструкции ни слова не сказано про УИН. Дело в том, что в таких электронных платёжках графа 22 заполняется автоматически, и здесь ставится 0. Изменять эти данные не нужно, платёж распознаётся по остальным реквизитам и паспортным данным плательщика.

Обязателен ли УИП при заполнении электронных платёжек

На самом деле при перечислении средств далеко не все организации требуют УИН или УИП, поэтому повышенный ажиотаж и сомнения по поводу этих идентификаторов буквально раздуты на пустом месте. Выше уже упоминалось, что универсальные идентификаторы необходимы для оптимизации учёта и систематизации поступающих платежей, поэтому они обязательно используются лишь учреждениями с большим потоком финансовых поступлений. Это могут быть налоговая служба или фонды соцстрахования. Но даже по реквизитам этих организаций платёж можно провести без заполнения поля 22.

Если речь идёт о налоговых сборах, которые взимаются с индивидуальных предпринимателей, функцию УИН вполне может выполнить код бюджетной классификации. Несколько другая ситуация складывается с физическими лицами, которые оплачивают налоги по присланным ФНС квитанциям. Здесь УИН является именно идентификатором транзакции, поэтому становится обязательным условием.

Оплата медицинских услуг и нахождения детей в дошкольных образовательных учреждениях обычно не требует дополнительной классификации, поэтому указание УИН и УИП в реквизитах платёжки не является обязательным условием.

Важно! Графу 22 нельзя оставлять пустой, иначе Сбербанк или другая кредитно-финансовая организация откажут в переводе средств. Если идентификаторы платежа неизвестны, в поле нужно проставить значение 0.

Что делать, если при указании УИП допущена ошибка

Человеческий фактор никто не отменял, поэтому подобные ошибки могут случиться с каждым. Первое, что нужно сделать, оказавшись в такой ситуации – повторить платёж, указав правильные данные. Это нужно для того, чтобы не образовалось просрочек по оплате, что обычно влечёт за собой штрафные санкции.

После этого необходимо отправить запрос на возврат ошибочно отправленных средств в службу поддержки Сбербанка, указав лицевой счёт для зачисления. Учитывая, что транзакции обычно выполняются в пользу госучреждений, проблем с возвратом обычно не возникает: здесь ведётся строгая бухгалтерская отчётность, и лишние суммы на счетах могут послужить поводом для аудиторской проверки. Однако обратный перевод может занять некоторое время, поэтому придётся запастись терпением.

Добрый день, Хабр!

Мы хотим сделать обзорный пост, посвящённый нашему новому проекту. Обзор затронет как функционал, так и техническую часть, надеемся, это сделает статью интересной как профессиональным разработчикам, так и тем, кто читает Хабр с целью держать руку на пульсе Технологии.

Тем, кому интересна только техническая сторона проекта - рекомендуем сразу перейти ко второй части .

ЧАСТЬ 1. Лирическая

Мы - это команда разработки сервиса личных страниц uid.me .
Личная страница - это, например, вот так:

http://uid.me/pavel_kudinov

Тем, кто не знаком с западным аналогом нашего сервиса, следует признаться: проект uid.me начинает свою историю как клон-локализация англоязычного сервиса about.me

История создания

Дело было так. Компания сайт-билдер uCoz, в которой мы трудимся, за 8 лет существования накопила в недрах своих дата-центров более 35 млн профилей, созданных веб-мастерами, а также многочисленными посетителями созданных веб-мастерами сайтов, форумов и блогов.

Всех этих людей объединяет глобальная система авторизации uID:

До сегодняшнего дня каждый человек, зарегистрированный в uCoz, имел профиль такого вида:

Проект about.me был выбран как лучший существующий прототип индивидуальной страницы для каждого пользователя uCoz, отвечающий, на наш взгляд, современному тренду самовыражения обитателей Сети начала XXI века.

Как и в случае about.me , мы даём пользователю:

1. Ставший правилом хорошего тона URL вида uid.me/имя_фамилия , который вполне можно использовать для печати на визитной карточке, указать в качестве домашней страницы в skype, а также упоминать на любом медиа-носителе.

2. Возможность объединить в единый визуальный образ личное фото, фоновое изображение в высоком разрешении, основную информацию о себе (такую как биография и сфера интересов).

3. Конструктор, с помощью которого можно быстро и увлекательно придать своей личной странице уникальный вид и общую визуальную согласованность.

4. И, наконец, самое интересное: сегодня многие из нас активно присутствуют в социальных сетях. Кому-то ближе форматы Facebook и Вконтакте, кто-то ограничивается микроблогами Twitter и Instagram, кое-кто имеет свой популярный канал на Youtube.

И здесь справедливо правило - чем большую социальную активность проявляет человек, тем острее встаёт вопрос: “какую из социальных сетей считать “главной”?”.

Мы предлагаем использовать uid.me в качестве своеобразной личной визитной карточки онлайн. Наш сервис позволяет привязать к собственному профилю наиболее распространённые социальные сети, и тогда не придётся выбирать - какую именно ссылку дать при новом ценном знакомстве, указать в профиле skype или поставить в подпись на форуме.

Ваши посты, твиты и фотографии будут автоматически появляться в вашем профиле, причём для отображения будет использован общий вид, а функция “поток” создаст общую ленту событий, объединяя в хронологическом порядке всё происходящее с вами.

Кстати, если вы захотите создать личную страницу на uid.me , рекомендуем воспользоваться автоматической регистрацией через социальную сеть. При клике по любой из кнопок “Войти через ” - личная страница будет мгновенно создана без необходимости вводить регистрационную информацию!

Забегая вперёд, хотим сказать, что тесная интеграция с социальными сетями в ближайшем будущем существенно сместит план развития проекта.

Вторая версия профилей uid.me , уже находящаяся в разработке, будет иметь главный фокус именно на функции объединения информации из социальных сетей в единый поток с настраиваемым представлением данных.

В дополнение планируется разработать несколько интересных инфографических виджетов в виде красочных графиков и диаграмм, представляющих информацию о ваших друзьях, путешествиях, музыкальных предпочтениях и прочие интересные занимательные факты, которые система сумеет извлечь из ваших профилей и обработать автоматически.

Возможно, это будет выглядеть как-то так:

ЧАСТЬ 2. Техническая

Разрабатывая uid.me под крылом uCoz, мы оказались в довольно необычном положении: с одной стороны, весь код проекта предполагалось написать с чистого листа, с другой стороны, в день релиза проект автоматически становился высоконагруженным, так как должен был импортировать в себя более 20 млн профилей, даже с учётом того, что бот-регистрации и совсем уж древние профили не прошли конкурс.

Тем не менее, мы решили сделать всё красиво и с использованием модных технологий, проведя таким образом разведку боем, получив много опыта и потенциальный левелап в итоге.

В качестве слагаемых успеха были выбраны:

0. Nginx. Куда без него.

1. База данных, из коробки решающая вопрос распределения данных на несколько серверов + отказоустойчивость при физическом выпадении сервера из кластера по любой причине. В этом качестве, несмотря на активные холивары, была выбрана MongoDB.

2. Гибкая схема данных, позволяющая без потерь проходить первичную и последующие фазы прототипирования функционала. Опять же помог MongoDB, хотя здесь пришлось заплатить ресурсами за удобство, так что получить главный ответ на вопрос: “BSON - это роскошь, или современное средство передвижения?” - ещё предстоит.

Стоит заметить, что исходная mysql база данных пользовательских профилей при конвертации в MongoDB формат выросла в 5 раз. Однако, каждый профиль при этом обогатился внушительным количеством новых данных, связанных с функционалом uid.me , поэтому дело не только в прожорливости гибкой схемы данных BSON.

3. Честно говоря, учитывая современную тенденцию к активному применению динамических JS интерфейсов (а также безмерное уважение к технологическому прорыву, сделанному инженерами Google при разработке V8 Javascript, на порядок обходящему по производительности все существующие скриптовые языки за счёт динамической компиляции в машинный код), закралась шальная мысль применить node.js и замкнуть круг веб-разработки на JavaScript, получив вместе с тем несколько жирных плюшек…

Но решили, что “один проект - одна новая технология, и нам пока что MongoDB ВОТ ТАК хватает ” (с) Александр Соловьев. Кстати, кто не видел этот его доклад - это хит, рекомендуем всем коллективом!

В итоге, в качестве серверной технологии решили оставить корпоративно-привычный Perl, однако нам удалось набрать вторую космическую скорость, покинуть гравитационное поле fast_cgi и применить Mojolicious - современный автономный и адекватный (не считая автора) веб-фреймворк с роутами, хелперами, бриджами, встроенной поддержкой асинхронных запросов и прочими положенными современному разработчику сладостями.

4. Тотальная асинхронность и кеширование данных при взаимодействии с социальными сетями.

К слову о прототипе проекта - было замечено, что данные из социальных сетей, полученные сервисом about.me, не обновляются, загружаясь лишь единожды - в момент подключения сервиса. Вероятно, опция обновления кеша доступна VIP пользователям, но нам не удалось добиться от about.me обновления информации. Это навело нас на мысли о том, что стоит по возможности как можно более качественно организовать межсерверное взаимодействие и систему кеширования, чтобы минимизировать риск возникновения схожих проблем в будущем.

Практически повсеместно внедрённый OAuth2 и схожесть в организации API различных социальных сетей дали возможность удачно обобщить взаимодействие.

Конечно, на этапе прототипа вся работа с API была синхронной, но блокировать Hypnotoad воркеры для осуществления API запросов в высоконагруженном проекте - однозначная роскошь и расточительство. К счастью, Mojolicious построен на весьма приличной, как по интерфейсу, так и по реализации, событийной машине, благодаря чему, кстати, каждый воркер в пуле способен параллельно обрабатывать не один (как в случае, скажем, с mod_perl), а десятки параллельных запросов, конечно, при условии, что те содержат значимое количество асинхронного кода.

К слову, учитывая то, что одним из основных “пугающих” аргументов против примененияnode.js является его тотальная асинхронность, - Mojolicious может послужить отличным ментальным мостом, когда вы начнёте разработку в рамках классической синхронной парадигмы, а закончите, как минимум, имея значительную часть гибридного кода (sync + async). Признаться, теперь мы боимся node.js значительно меньше и надеемся применить его в последующих проектах.

Вообще, uid.me делался по принципу “нет велосипедам”, и в жертву Шиве был торжественно принесён целый пласт ископаемых самоделок, возглавляемый широко известным в узких кругах килобайтным макросом “dw ”, с 2005 года верой и правдой служивший нам и близким нам разработчикам и позволивший в трудный час избежать трансцендентного ужаса DBIx::Class. Светлая память.

И всё же, при разработке uid.me родилась одна занимательная поделка - это макрос

Take { … $take->(‘named_callback_slot_1’) ... } process { my $taken = shift; … },

Построенный на Mojo::IOLoop->delay и радикально упрощающий весь цикл операций, связанных с организацией именованных каскадных асинхронных API взаимодействий, включая каскадную обработку исключений (при возникновении интереса - пишите в личное, поделимся).

Возвращаясь к MongoDB

Применить на практике что-то похожее на NoSQL решение хотелось ещё с тех времён, когда это не было мейнстримом. В рамках тех highload задач, с которыми в то время приходилось сталкиваться, постепенно нарисовалось следующее понимание:

1. Классический LAMP проект стартует с классической SQL БД.
2. Если проект становится популярным, он обретает статус «highload», иначе goto 1.
3. Статус «highload» обязывает нас вплотную задуматься о кешировании, шардировании, репликации и
бекапе того, что хранится в SQL БД.
4. Эволюция схемы данных живого проекта становится тем более болезненной, чем больше данных накоплено, и тем более востребованной, чем более популярным оказался проект.
5. В результате всего этого ORM код начинает выполнять функции mutex, сериализации/десериализации данных для memcached, примитивного шардирования, в особо жестоких ситуациях - патчи обеспечения обратной совместимости схемы данных (ибо позволить себе большой сквозной апдейт данных в реальных условиях удавалось далеко не всегда).

Впрочем, довольно о грустном, на дворе были суровые 2000"е.

Начало 2010"х было озарено появлением нескольких NoSQL решений, которые обещали устранить бОльшую часть проблем растущего highload проекта «из коробки». Появление открытых, готовых к использованию NoSQL решений пророчили многие, но, тем не менее, фактическое обретение прекрасного будущего нас приятно удивило.

Посоветовавшись с более экстремальными в плане новшеств коллегами, мы решили пробовать MongoDB .

Изучая новую для себя технологию, мы посчитали логичным применить её возможности по максимуму, надеясь на лучшее (а значит, на серебряную пулю из коробки), рассчитывая, впрочем, откатиться к более классическим техникам в тех местах, где чрезмерная наглость столкнула бы нас с интересными подводными камнями.

Под применением возможностей по максимуму мы подразумеваем следующее:

1. JSON формат хранения данных позволил не возиться с привычными parent/child/x-связями в схеме данных по поводу и без, ограничившись здравым смыслом. В результате вложенная структура основного объекта user оказалось жирной, но удобной. В неё смело вложили кучу флажков, настроек отображения, мелких связанных списков и всего того прочего, что раньше с ходу приводило к созданию пачки около-user"овых SQL таблиц.

2. В модель данных добавили код общего назначения, который на этапе прототипирования интерфейса позволил крайне приятно наращивать JS функционал: по URL /profile/save стало возможным послать любой JSON, который extend"ил объект пользователя новыми данными, например:

User.save({ "style.profile.top": "20px", "style.caption.tags.color": "rgba(30, 29, 38, 1)", "info.first_name": "Павел" });

Все операции, связанные с деятельностью авторизованного пользователя были упакованы в общую функцию отправки с латентным коллектором в 500 мсек, объединяющим различные атомарные правки в общие пакеты.

В результате, client-side разработчики смогли легко расширять структуру объекта user, просто начиная использовать новые поля.

Конечно, после фазы прототипирования, серверная часть /profile/save была снабжена контекстными фильтрами данных, которые отсекали неизвестные поля и фильтровали значения на предмет корректности.

Осталась только одна проблема - в БД могли храниться пользователи, у которых вообще не существовали некоторые поля, так как последний раз они редактировали свой профиль ещё до того, как эти поля возникли. В идеале, хотелось бы иметь default-значения для каждого поля, которые будут магическим образом появляться в любом объекте, извлекаемом из БД.

Видел на форуме и сайте кучу вопросов, таких как:
- "А че такое уид??"
- "Зачем нужен uid?"
- "Где взять этот uid?"
-
- "Расскажите про уид!"

Итак, начнем...
UID

-

UID.
-


-

По определению, UID-тип

характеристики:
-

-


-

UID-тип это объект типа TUidType

UID можно в любое время посмотреть, зайдя например в программу SmartFileMan, и нажав клавишу "5" на нужном файле.На экране появятся все три UID-a...

Что такое UID. И с чем его едят.

В Symbian OS UID-ы используются повсеместно для разнообразных идентификаций типов
файлов и увязки файлов с теми или иными приложениями. Конечно, пользователю более понятны обычные
имена файлов и Symbian OS гибко поддерживает имена файлов различной длинны. Но с точки зрения системы,
32-битные номера обеспечивают большую однозначность, систематичность и более легкую идентификацию.
Поэтому UID-ы являются фундаметальной характеристикой ОС.

По определению, UID-тип объекта состоит из трех отдельных UID-ов используемых
в комбинациях. Составные компоненты UID-ов называются UID1, UID2 и UID3 имеют следующие основные
характеристики:
- UID1- может быть рассмотрен как идентификатор на уровне системы; например, исполняемые файлы,
DLL, файловые хранилища все различаются по UID1.
- UID2-различия между объектами имеющими один и тот же UID1 и могут быть рассмотрены как идентификатор
интерфейса; например, статический интерфейс (разделяемая библиотека) и полиморфический интерфейс
(приложение или встраеваемая программная оболочка) DLL-ки отличаются по UID2.
- UID3-идентифицирует объекты, имеющие конкретный UID2 и может рассматриваться как идентификатор
проекта; например, UID3 может быть разделен между всеми объектами, принадлежащими данной программе,
включая библиотеки, если имеются, DLL-ки каркасов,и все документы.

UID-тип это объект типа TUidType , которой можно создать из комбинаций всех
или некоторых из трех возможных UID-ов. Если переменная имеет прелставляет собой UID, то можно выяснить
и значения составляющих её компонентов UID1, UID2 и UID3.

Объект в Symbian OS и, особенно, многие файлы в Symbian OS могут иметь все, несколько,
или вообще не иметь не одного из трех возможных UID-ов.

Вариант с отсутсвием UID-ов необходим для того, чтобы можно было взаимодействовать
с другими системами, позволяя легко и свободно использовать по назначению в Symbian OS не родные
файлы данных. Symbian OS позволяет создавать настраиваемые файловые ассоциации и идентификации даже
когда UID-ы отсутсвуют. Это делается по расширениям имен файлов.

Каждый "родной" документ должен иметь соотвествующий UID1. его значение задается
приложением, создавщим этот документ.

Необходимым является только UID1, но в большинстве случаев разработчики захотят
определить второй и третий UID-ы для документов, которые создает и использует их приложение. Значения
этих UID используются каркасом архитектуры приложения, чтобы управлять связями между приложениями
и их документами. Например, это позволяет при открытии файла определить и запустить связанное с ним
приложение, а также правильно отображать иконку этого приложения, возле файла документа. И наоборот
это позволяет приложению, отсортировывать свои файлы среди прочих.

UID задается из диапазона 0х01000000 до 0x0fffffff.

UID можно в любое время посмотреть, зайдя например в программу SmartFileMan, и нажав клавишу "5" на нужном файле.На экране появятся все три UID-a...">

Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к системным ресурсам (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы совпадают, т.е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя, путем установки бита SUID , когда эффективному идентификатору присваивается значение идентификатора владельца выполняемого файла (например, пользователя root ).

Реальный (GID) и эффективный (EGID) идентификаторы группы

Реальный идентификатор группы равен идентификатору основной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам от имени группы. Обычно эффективный идентификатор группы совпадает с реальным. Но если для выполняемого файла установлен бит SGID , такой файл выполняется с эффективным идентификатором группы-владельца.

Атрибуты файлов

Аннотация

Аналогично файловой системе FAT, имеющей атрибуты файлов (архивный, системный файл, скрытый), в файловой системе ext2fs также имеются свои собственные, но они отличаются. Мы вкратце пройдемся по ним для полноты повествования, но используются они очень редко. Однако, если вы действительно хотите получить защищенную систему - читайте дальше.

Существует две команды для управления атрибутами файла: lsattr(1) и chattr(1) . Вы, наверное, догадались, что команда lsattr выводит список (LiSt) атрибутов, а команда chattr изменяет (CHange) их. Эти атрибуты могут быть установлены только для каталогов и обычных файлов. Доступны следующие атрибуты:

1. A («no A ccess time»): если для файла или каталога установлен этот атрибут, то, всякий раз при обращении к нему для чтения или записи, у него не будет обновляться время последнего доступа. Это может быть полезно, например, для файлов и каталогов, к которым очень часто обращаются для чтения, особенно из-за того, что это единственный параметр в inode, который изменяется при открытии файла только для чтения.

2. a («a ppend only»): если для файла установлен этот атрибут, и этот файл открыт для записи, то единственной доступной операцией будет добавление данных к его предыдущему содержимому. Для каталога это означает, что вы сможете только добавить файлы, но не сможете переименовать или удалить ни одного из существующих файлов. Только root может установить или снять этот атрибут.

3. d («no d ump»): dump (8) - это стандартная утилита UNIX ® для резервного копирования. Она делает дамп любой файловой системы, для которой счетчик дампов в файле /etc/fstab (5-е поле) равен 1 (см. главу Глава 8, Файловые системы и точки монтирования ). Но если этот атрибут установлен для файла или каталога, то он, в отличие от других, будет будет пропущен при снятии дампа. Обратите внимание, что при установке его для каталогов, это также распространяется на все их подкаталоги и файлы.

4. i («i mmutable»): файл или каталог с установленным этим атрибутом вообще не может быть изменен: он не может быть переименован, на него не может быть создана ссылка и он не может быть удален. Только root может установить или снять этот атрибут. Обратите внимание, что это также предотвращает изменение времени последнего доступа, поэтому вам нет необходимости устанавливать атрибут A , если установлен i .

5. s («s ecure deletion»): когда удаляется файл или каталог с этим атрибутом, блоки, которые он занимал на диске перезаписываются нулями.

6. S («S ynchronous mode»): если для файла или каталога установлен этот атрибут, все его изменения синхронизируются и немедленно записываются на диск.

К примеру, вы можете установить атрибут i на жизненно важные системные файлы, чтобы избежать неприятных сюрпризов. Также, рассмотрите вариант установки атрибута A на страницы руководств: это позволит избежать многих дисковых операций, и, в частности, может немного продлить жизнь аккумуляторов портативных компьютеров.

15.Порождение процессов в системе