Классическая БД при записи данных не требует "доверенной" стороны. Права на вставку/изменение/удаление данных в ней регулируется правами пользователя БД. Хотя в своем собственном приложении (имея необходимые права на уровне пользователя БД) вы можете "выдумать" и собственные права работы с данными... :-) Возможность "забыть то что было" неоспоримое преимущество классических БД. И проистекает оно из простой истины "внешний мир" (преимущественно) не может взаимодействовать с данными БД "напрямую" и всегда есть "прокладка" в виде "кожаного мешка". А людям свойственно ошибаться, и при написании ПО и при взаимодействием с ним. И зачастую исправлять уже допущенные ранее ошибки в данных другими методами чем "забудь старое и вот исправленные данные" на порядки сложнее (чем к примеру метод "вот тебе новые данные для корректировки/исправления ранее уже допущенных ошибок") или просто иногда не возможно... Люди очень изобретательны в своих ошибках.... :-)
К примеру вы проектируете будущую систему, и честно (по схеме) на вопрос "Необходимо ли вашей системе доверие третьей стороны?" - отвечаете "Нет". Строите свое блокчейн хранилище. А "завтра" госрегулятор вам "говорит" "Ваша система обязана доверять доверять организации .....". Ваши действия? Все "по новому"? :-)
:-) Oracle - Number having precision p and scale s. The precision p can range from 1 to 38. The scale s can range from -84 to 127. Both precision and scale are in decimal digits. A NUMBER value requires from 1 to 22 bytes. PostgeSQL - bigserial 8 bytes large autoincrementing integer1 to 9223372036854775807
Технология оплаты токенами описана верно и правильно, именно она и обеспечивает безопасность платежей. А вот все остальное (касающееся "банковской" части) описано "с точки зрения" сбера и его технологий... :-) Токен - это просто идентификатор в конкретной платежной системе. Он может быть связан как с платежной картой, так и "непосредственно" с конкретным счетом клиента в конкретном банке - участнике платежной системой. Именно платежная система при оплате токеном "преобразует" его в "связанный" с ним идентификатором платежного средства. В НСПК это номер счета, для платежной системы МИР (как и для международных платежных систем VISA/Mastercard) номер карты (такой же идентификатор для платежных систем который в "конечном счете" "ведет" к номеру счета клиента в конкретном банке).
:-) У вас в базе максимум миллиард объектов и тысяча миллиардов записей действий с ними.... А уж индексов их включающих... Скажем так "много". Я не говорю даже о объеме информации хранения (она разная особенно для UTF8 VARCHAR). А вот скорость работы (и объем) с индексами по NUMBER и VARCHAR полям отличается значительно. Причем "специальный" UUID data type на индексах производительностью совсем "не блещет"...
Ну как бы главный налоговый "рекетир" делает сейчас все что может, для того чтобы деньги "всегда можно было найти" (особенно безналичные)... И при этом очень "не любит" если деньги от его налогов скрывают (что делает крипта)... :-)
:-) Слова это хорошо, но дела "говорят" больше... Пример "из жизни".... :-) У человека рублевый карта/счет в российском банке, на который он получает "белую" зарплату. Во сколько и как долго по времени ему обойдется перевод другому человеку (в другом российском банке и на другой рублевый счет/карту) 1000 рублей? Сколько он потратит рублей и времени на это (когда другой человек сможет уже потратить полученную 1000 рублей)? "Без комиссии" и "мгновенно"... Но желательно все же "по шагам" и "в цифрах" поподробнее расписать... :-)
Статья (как и предыдущая этого автора) вполне адекватная и здравая. Как много вы знаете хороших и успешных рыбаков выдающих хорошие рыбные места? Почему же в случае финансов и их умножения должно быть по другому? Игра на бирже, вложение в акции или крипту - высокорискованные финансовые операции, и это никем не отрицается. Ни один минусующий автора не опроверг его посыл что покупать ежедневно хлеб и молоко за крипту никто не будет. За крипту больше всех "топят" в основном те, кто разными путями в любом случае зарабатывает на "новых адептах" этой пирамиды, ну и небольшая часть тех кто просто не понимает "как это работает", но уже "впряглись" и боятся потери своих сбережений. Ровно так же как "адепты" игры на бирже, финансовых пирамид и вложения в сомнительные стартапы. Этот факт можно отрицать - но это остается фактом. Спекуляция на человеческой жадности и (скажем прямо) глупости определенной категории людей - неистребима.
Ну как бы это такое желание присуще всем живым существам... :-) Инстинкты... Но... Кроме желания всегда еще существуют "возможности", и "люди разумные" прекрасно понимают своей головой недостижимость данного инстинкта и начинают разумно соотносить свои желания со своей ответственностью, своими возможностями и желаниями других окружающих их людей. Ну а поскольку "люди разные", такое "понимание" у всех развито в разной степени. Как то так...
Я имел опыт работы с Windows UMPC (Sony Vaio VGN-UX1XRN) и Windows планшетами (на x5 Z8300). Первый имел не очень удобную клавиатуру, 2 GB RAM max и резистивный экран, на планшете (4 GB RAM) тем более не удобное управление в Windows как оказалось, и производительность не очень. Сейчас жду доставки вот такой штуки - https://www.ozon.ru/product/8-noutbuk-byone-p8-intel-processor-n100-ram-12-gb-ssd-intel-hd-graphics-windows-pro-1079150861 . На мой взгляд (хотя кому как) на текущий момент - то что нужно для Intel UMPC, c адекватным соотношением всех характеристик, функций и цены...
в PG (и его клонах) UPDATE = INSERT (с нюансами индексов и AUTOVACUUM)... Маркетинговые заявления и показатели на "подточенных" тестах (не важно каких компаний) "по факту" плохо согласуются с результатами тестов на реальных бизнес приложениях...
:-) Можно использовать все что угодно... Хоть Oracle RAC, но блокировки блоков данных в памяти (для синхронизации их в отдельных нодах) через сетевые (или проприетарные) интерфейсы всегда будут тормозить транзакции БД... AWS же не даром упоминает в рекламе Aurora ускорение только чтения... :-)
"Вывод пользователю сообщения об ошибке - ожидаемый результат выполнения ПО, это не баг и не уязвимость." - а я то "тупой пользователь" думал что ошибок в ПО быть не должно, а вот "защита от дурака" быть обязана... :-) А тут вон оно как... Ошибки "ожидаемый результат выполнения ПО"! :-) И "логика ПО" совершенно не обязана предусматривать все возможные действия пользователя! :-) Поле "номер телефона" в диалоге ввода не нужно ограничивать цифрами и валидировать пользовательский ввод. Пусть пользователь вводит туда все что хочет! К примеру ранее скопированный пользователем в буфер обмена видео файл! Пусть после этого приложение молча упадет! Это же предусмотрено его функциональностью? Замечательное у вас ПО и требования к его функциональности! :-)
Классическая БД при записи данных не требует "доверенной" стороны. Права на вставку/изменение/удаление данных в ней регулируется правами пользователя БД. Хотя в своем собственном приложении (имея необходимые права на уровне пользователя БД) вы можете "выдумать" и собственные права работы с данными... :-)
Возможность "забыть то что было" неоспоримое преимущество классических БД. И проистекает оно из простой истины "внешний мир" (преимущественно) не может взаимодействовать с данными БД "напрямую" и всегда есть "прокладка" в виде "кожаного мешка". А людям свойственно ошибаться, и при написании ПО и при взаимодействием с ним. И зачастую исправлять уже допущенные ранее ошибки в данных другими методами чем "забудь старое и вот исправленные данные" на порядки сложнее (чем к примеру метод "вот тебе новые данные для корректировки/исправления ранее уже допущенных ошибок") или просто иногда не возможно...
Люди очень изобретательны в своих ошибках.... :-)
"Подобная смена условий" не повлияет катастрофически на архитектуру вашей системы, если вы не будете использовать БД на блокчейне... :-)
К примеру вы проектируете будущую систему, и честно (по схеме) на вопрос "Необходимо ли вашей системе доверие третьей стороны?" - отвечаете "Нет". Строите свое блокчейн хранилище. А "завтра" госрегулятор вам "говорит" "Ваша система обязана доверять доверять организации .....". Ваши действия? Все "по новому"? :-)
:-)
Oracle - Number having precision
pand scales. The precisionpcan range from 1 to 38. The scalescan range from -84 to 127. Both precision and scale are in decimal digits. ANUMBERvalue requires from 1 to 22 bytes.PostgeSQL - bigserial 8 bytes large autoincrementing integer1 to 9223372036854775807
:-) Теоретизировать - это хорошо... Вы на практике в БД попробуйте и сравните.... :-)
Технология оплаты токенами описана верно и правильно, именно она и обеспечивает безопасность платежей. А вот все остальное (касающееся "банковской" части) описано "с точки зрения" сбера и его технологий... :-)
Токен - это просто идентификатор в конкретной платежной системе. Он может быть связан как с платежной картой, так и "непосредственно" с конкретным счетом клиента в конкретном банке - участнике платежной системой. Именно платежная система при оплате токеном "преобразует" его в "связанный" с ним идентификатором платежного средства. В НСПК это номер счета, для платежной системы МИР (как и для международных платежных систем VISA/Mastercard) номер карты (такой же идентификатор для платежных систем который в "конечном счете" "ведет" к номеру счета клиента в конкретном банке).
:-) У вас в базе максимум миллиард объектов и тысяча миллиардов записей действий с ними.... А уж индексов их включающих... Скажем так "много".
Я не говорю даже о объеме информации хранения (она разная особенно для UTF8 VARCHAR). А вот скорость работы (и объем) с индексами по NUMBER и VARCHAR полям отличается значительно. Причем "специальный" UUID data type на индексах производительностью совсем "не блещет"...
Ну как бы главный налоговый "рекетир" делает сейчас все что может, для того чтобы деньги "всегда можно было найти" (особенно безналичные)... И при этом очень "не любит" если деньги от его налогов скрывают (что делает крипта)... :-)
Вот я и думаю, а причем тут крипта.... :-)
Ну как бы ваш фиат все же правоохранительные органы вернуть могут... Если найдут кто к вам "заходил"... А вот с криптой - проблемы все ваши...
:-) А потом к вам "случайно" заходят пара крепких ребят с битами и паяльником... И холодный кошелек становится "уже не ваш"... Ваши действия?
:-) Слова это хорошо, но дела "говорят" больше...
Пример "из жизни".... :-)
У человека рублевый карта/счет в российском банке, на который он получает "белую" зарплату. Во сколько и как долго по времени ему обойдется перевод другому человеку (в другом российском банке и на другой рублевый счет/карту) 1000 рублей? Сколько он потратит рублей и времени на это (когда другой человек сможет уже потратить полученную 1000 рублей)?
"Без комиссии" и "мгновенно"... Но желательно все же "по шагам" и "в цифрах" поподробнее расписать... :-)
Статья (как и предыдущая этого автора) вполне адекватная и здравая.
Как много вы знаете хороших и успешных рыбаков выдающих хорошие рыбные места?
Почему же в случае финансов и их умножения должно быть по другому?
Игра на бирже, вложение в акции или крипту - высокорискованные финансовые операции, и это никем не отрицается.
Ни один минусующий автора не опроверг его посыл что покупать ежедневно хлеб и молоко за крипту никто не будет.
За крипту больше всех "топят" в основном те, кто разными путями в любом случае зарабатывает на "новых адептах" этой пирамиды, ну и небольшая часть тех кто просто не понимает "как это работает", но уже "впряглись" и боятся потери своих сбережений. Ровно так же как "адепты" игры на бирже, финансовых пирамид и вложения в сомнительные стартапы. Этот факт можно отрицать - но это остается фактом. Спекуляция на человеческой жадности и (скажем прямо) глупости определенной категории людей - неистребима.
Ну как бы это такое желание присуще всем живым существам... :-) Инстинкты...
Но... Кроме желания всегда еще существуют "возможности", и "люди разумные" прекрасно понимают своей головой недостижимость данного инстинкта и начинают разумно соотносить свои желания со своей ответственностью, своими возможностями и желаниями других окружающих их людей. Ну а поскольку "люди разные", такое "понимание" у всех развито в разной степени. Как то так...
Я имел опыт работы с Windows UMPC (Sony Vaio VGN-UX1XRN) и Windows планшетами (на x5 Z8300). Первый имел не очень удобную клавиатуру, 2 GB RAM max и резистивный экран, на планшете (4 GB RAM) тем более не удобное управление в Windows как оказалось, и производительность не очень. Сейчас жду доставки вот такой штуки - https://www.ozon.ru/product/8-noutbuk-byone-p8-intel-processor-n100-ram-12-gb-ssd-intel-hd-graphics-windows-pro-1079150861 . На мой взгляд (хотя кому как) на текущий момент - то что нужно для Intel UMPC, c адекватным соотношением всех характеристик, функций и цены...
в PG (и его клонах) UPDATE = INSERT (с нюансами индексов и AUTOVACUUM)... Маркетинговые заявления и показатели на "подточенных" тестах (не важно каких компаний) "по факту" плохо согласуются с результатами тестов на реальных бизнес приложениях...
:-) Можно использовать все что угодно... Хоть Oracle RAC, но блокировки блоков данных в памяти (для синхронизации их в отдельных нодах) через сетевые (или проприетарные) интерфейсы всегда будут тормозить транзакции БД...
AWS же не даром упоминает в рекламе Aurora ускорение только чтения... :-)
А кто-то знает не монолитные OLTP ACID DB, которые можно эффективно "размазать по микросервисам" на нескольких физических серверах? :-)
Ну для инвертора то стабилизаторы штука незаменимая... :-)
"Вывод пользователю сообщения об ошибке - ожидаемый результат выполнения ПО, это не баг и не уязвимость." - а я то "тупой пользователь" думал что ошибок в ПО быть не должно, а вот "защита от дурака" быть обязана... :-)
А тут вон оно как... Ошибки "ожидаемый результат выполнения ПО"! :-)
И "логика ПО" совершенно не обязана предусматривать все возможные действия пользователя! :-)
Поле "номер телефона" в диалоге ввода не нужно ограничивать цифрами и валидировать пользовательский ввод. Пусть пользователь вводит туда все что хочет! К примеру ранее скопированный пользователем в буфер обмена видео файл!
Пусть после этого приложение молча упадет! Это же предусмотрено его функциональностью? Замечательное у вас ПО и требования к его функциональности! :-)