>> Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
В таком случае нужно понимать что такое FullStack разработчик. В моем понимании это разработчик, который способен написать приложение от и до без посторонней помощи. А не так, что если нужны триггеры, то я уже не FullStack разработчик.
Мало чего принципиально нового. В статье указан интерфейс Сбербанка, но уже несколько лет, как он обновлен и теперь он много лучше. Например, вот вам принципиально новая идея: клиент с телефона выбирает банкомат и выбирает действие (например, снять 1500 рублей банкнотами по 500 + 10 * 100) вставляет карту в банкомат и тот уже знает чего он хочет и сразу ему предлагает это сделать.
В языках программирования var нужен не столько для того, чтобы просто укоротить запись, а скорее для ситуаций когда невозможно (на этапе написания кода) определить какого типа будет результирующий объект.
Например, при использовании LINQ на языке C#: int[] arr = new int[] { 1, 2, 3, 4, 5 };
var result = arr.Select(x => new { x, mod2 = x % 2 }).ToArray();
Так как при проецирование используется анонимный класс, то на момент написания кода нет возможности определить какого типа вернется объект. Это будет массив классов, но имена этим классам будут присвоены лишь на момент компиляции.
>> можно было бы наносить разметку краской, отражающей радиоволны.
Можно. Но также легко представить себе недовольного своей жизнью школьника, который по ночам будет вам такую разметку рисовать. Посмотрите на стены, которые изрисованы граффити. Мы не в идеальном обществе живем.
>> Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
Криптографическая стойкость при этом пострадает. Любое упрощение аутентификации не должно приводить к дырам в безопасности. Если вы уж решили ограничиться только паролем, то хотя бы его надо хранить грамотно.
>> И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
>> пароль генерируем сами, уникальным
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
>> водит свой пароль, берем от него хеш (с солью)
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
>> если они настолько просты, что совпадают
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
>> мы рассчитываем и фиксируем стоимость поездки сразу
За это вам конечно спасибо. Но обычные таксисты фиксировали стоимость до поездки всегда т.е. тут вы их мало чем превзошли.
>> рассчитана с повышающим коэффициентом — он срабатывает в те моменты,
И как раз вот эти коэффициенты спрогнозировать практически невозможно т. е. нельзя знать стоимость заказа хотя бы за полчаса.
>> Но при этом ценообразование становилось совершенно непрозрачным — вы не могли точно предсказать, сколько будет стоить поездка
Здесь вы дико лукавите. 13 июня я спланировал поездку домой на Яндекс.Такси. В 17:03 проверил стоимость маршрута и это была сумма в 181 рубль. Я отложил 200 рублей на поездку. Но когда заказал такси в 20:05, то она мне вдруг вышла в 445 рублей т.е. в 2,5 раза дороже.
Отлично я предсказал стоимость поездке с Яндекс.Такси?
>> 2.5% пользователей это много миллионов пользователей.
Нет. 2.5% пользователей это лишь 2.5% потенциальных клиентов. Это еще раз подтверждает, что у вас нет своего успешного бизнеса. Иначе вы бы не называли покрытие потенциальных клиентов в 2.5% огромным.
>> Отличная идея придумать за меня кого куда мы послали.
На самом деле будет отличной идеей вообще не общаться с вами.
>> И Вам ведь неинтересно что мы продаем
Мы сейчас обсуждаем решение по подтверждению заказов в Юлмарт. Всем прекрасно известно, чем он торгует. Или вы хотите, чтобы мы обсуждали крошечный бизнес которому достаточно ограничится сообщениями в телеграмм?
>> Знаете анекдот старый есть?
Да, знаю. Только причем здесь он? Телеграмм особо не скрывает информацию о распространённость в той или иной стране. Или вы просто пытаетесь отшутиться, после того, как полную глупость написали?
>> Конечно я общаюсь нормально.
Это не так.
>> Перечитайте что я написал и не задавайте глупых вопросов.
Вы сами то статью читали? Речь идет не об информировании, а о подтверждении заказа. Разницу видите? В одном случае вы просто шлете информацию пользователю, а в другом ожидаете от него каких-либо действий. Например, при смс это может быть ответное смс с таким-то кодом, при чате в телеграмм ответное сообщение с таким-то текстом. И все это одним словом называет опрос, потому что задается вопрос и на него ожидается ответ.
P.S. Сомневаюсь, что у вас есть какой-либо бизнес. С такой манерой поведения люди обычно занимают крайне второстепенные должности.
>> Это вы не учитываете, что у огромного количества людей он есть
Огромное число, по сравнению с количеством людей, которые имеют телефонные номера? Вы сейчас серьезно?
>> или только потрындеть ради пишете?
Ничего себе какой вы хам. Нормально общаться не умеете?
>> При чем тут опросы?
А подтверждение заказа это не опрос, а как бы вы это оформили в телеграмм?
>> подтверждение заказов давно есть телеграмм
У вас, наверное, бизнес для молодежи и вы не учитываете, что у огромного количества людей нет телеграмма.
>> смс на худой конец
Вы сами часто отвечаете на смс, которые к вам приходят с различными опросами? Я вот никогда не отвечаю.
Скажите, пожалуйста, если клиент не смог ответить и пытается перезвонить, то что он услышит?
Робот и клиент обычно действуют медленнее, чем живые люди в диалоге. Не компенсирует ли увеличившаяся оплата телефонных переговоров уменьшение штата в колл-центре?
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
Например, при использовании LINQ на языке C#:
int[] arr = new int[] { 1, 2, 3, 4, 5 };var result = arr.Select(x => new { x, mod2 = x % 2 }).ToArray();
Так как при проецирование используется анонимный класс, то на момент написания кода нет возможности определить какого типа вернется объект. Это будет массив классов, но имена этим классам будут присвоены лишь на момент компиляции.
Можно. Но также легко представить себе недовольного своей жизнью школьника, который по ночам будет вам такую разметку рисовать. Посмотрите на стены, которые изрисованы граффити. Мы не в идеальном обществе живем.
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
Вы совсем не любите своих пользователей.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
За это вам конечно спасибо. Но обычные таксисты фиксировали стоимость до поездки всегда т.е. тут вы их мало чем превзошли.
>> рассчитана с повышающим коэффициентом — он срабатывает в те моменты,
И как раз вот эти коэффициенты спрогнозировать практически невозможно т. е. нельзя знать стоимость заказа хотя бы за полчаса.
Здесь вы дико лукавите. 13 июня я спланировал поездку домой на Яндекс.Такси. В 17:03 проверил стоимость маршрута и это была сумма в 181 рубль. Я отложил 200 рублей на поездку. Но когда заказал такси в 20:05, то она мне вдруг вышла в 445 рублей т.е. в 2,5 раза дороже.
Отлично я предсказал стоимость поездке с Яндекс.Такси?
Нет. 2.5% пользователей это лишь 2.5% потенциальных клиентов. Это еще раз подтверждает, что у вас нет своего успешного бизнеса. Иначе вы бы не называли покрытие потенциальных клиентов в 2.5% огромным.
>> Отличная идея придумать за меня кого куда мы послали.
На самом деле будет отличной идеей вообще не общаться с вами.
>> И Вам ведь неинтересно что мы продаем
Мы сейчас обсуждаем решение по подтверждению заказов в Юлмарт. Всем прекрасно известно, чем он торгует. Или вы хотите, чтобы мы обсуждали крошечный бизнес которому достаточно ограничится сообщениями в телеграмм?
Да, знаю. Только причем здесь он? Телеграмм особо не скрывает информацию о распространённость в той или иной стране. Или вы просто пытаетесь отшутиться, после того, как полную глупость написали?
>> Конечно я общаюсь нормально.
Это не так.
>> Перечитайте что я написал и не задавайте глупых вопросов.
Вы сами то статью читали? Речь идет не об информировании, а о подтверждении заказа. Разницу видите? В одном случае вы просто шлете информацию пользователю, а в другом ожидаете от него каких-либо действий. Например, при смс это может быть ответное смс с таким-то кодом, при чате в телеграмм ответное сообщение с таким-то текстом. И все это одним словом называет опрос, потому что задается вопрос и на него ожидается ответ.
P.S. Сомневаюсь, что у вас есть какой-либо бизнес. С такой манерой поведения люди обычно занимают крайне второстепенные должности.
Огромное число, по сравнению с количеством людей, которые имеют телефонные номера? Вы сейчас серьезно?
>> или только потрындеть ради пишете?
Ничего себе какой вы хам. Нормально общаться не умеете?
>> При чем тут опросы?
А подтверждение заказа это не опрос, а как бы вы это оформили в телеграмм?
У вас, наверное, бизнес для молодежи и вы не учитываете, что у огромного количества людей нет телеграмма.
>> смс на худой конец
Вы сами часто отвечаете на смс, которые к вам приходят с различными опросами? Я вот никогда не отвечаю.
Робот и клиент обычно действуют медленнее, чем живые люди в диалоге. Не компенсирует ли увеличившаяся оплата телефонных переговоров уменьшение штата в колл-центре?