переводы пользователь-пользователь с последующим выводом наличкой (почта) или на счёт можно делать?
Да, можно. Платежи между пользователями, конечно же, есть.
Комиссия — полпроцента.
Насчет вывода — не-не, пользователь может вывести из системы всю сумму, которая будет на счету. Какая при этом будет комиссия — зависит от способа вывода. Официально через ДМР — 5%. Через вывод на виртуальную карту — 3% с копейками. Более экзотичные способы (их можно придумать, ага) — зависит от.
За замечания спасибо, передам «куда надо».
Если интересно прямо сейчас, вот ответы на большое количество вопросов по виртуальной визе на сайте банка, через которого процессим. Почему на них не дали хотя б ссылку на сайте ДМР — большой, большой вопрос, это да.
На днях пресс-релизили новость про начало работы с магазинами. Там немножко про преимущества для бизнеса. Еще на роеме новость была, там комментарии от директора по развитию были. Если вкратце — небольшая комиссия + доступ к аудитории Мэйла при активной поддержки со стороны портала.
Про преимущества для пользователя расскажу со своей колокольни, благо пользуюсь.
Что важно для пользователя интернета в произвольной платежной системе?
— куча дешевых способов ввода
— куча способов вывести в что-нибудь полезное.
Если говорить о ДМР, то ввести можно не очень большим количеством способов — терминалы, инет-банкинг, пластиковые карты (как раз в заголовке — о 0% по вводу).
А вот с точки зрения вывода помимо обычных сотовых-провайдеров-телевидения (и покупки Visa Virtual, дающей доступ вообще к куче вещей, правда, уже без участия ДМР) Деньги Мэйла открывают для пользователя вход в кучу мэйловых проектов, включая большое количество игрушек. Понятное дело, что для кого-то это никакое не преимущество, но для очень большого количества пользователей, как видно из последних года-двух развития Рунета, это неоспоримый плюс.
Физически покупка уже работает, и найти нужную форму тоже уже можно, минуя указанную промо-страницу — непосредственно через каталог. Пресс-релиз, видимо, на подходе.
Просто у вас второй и третий пункты тоже очень категоричны.
Эт все из опыта. Я неоднократно видел проблемы, которых можно было бы избежать, потратив какое-то разумное время на проектирование. Точно так же, как не видел ни одного использования ОРМа в более-менее серьезном проекте, где в итоге не пришли бы к прямому выполнению SQL-запросов или не вносили бы изменений в архитектуру исключительно, чтобы исправить проблемы ОРМа.
Пример: заказчик захотел добавить новое поле к учётке пользователя
Так если изменения постоянны, то скрипты миграции можно не заносить в релизную ветку. Можно же просто сохранить новую схему таблиц и зафиксировать в документации, что после такой-то ревизии код несовместим с предыдущими релизами.
В общем, опять же — у меня хватает примеров хранения sql-кода в репозитории, когда заносятся или пакеты (если СУБД их поддерживает), или функции, сгруппированные в файлы на подобие пакетов (если СУБД не поддерживает пакеты).
Я в чём-то не прав?
При желании, можно извратиться как угодно. Вам самому не кажется странным, что вместо одной сущности — СУБД — у вас добавляется еще две: кэш и орм? Как же принцип K.I.S.S? =) Ну да ладно.
Продолжение спора, в общем-то, непринципиально, ага.
Вы чересчур категоричны.
Я могу аргументировать каждое свое предложение.
А Вы?
Переменные — нужны.
Более того, переменные в большинстве известных мне языков программирования СУБД есть.
Массивы не везде, но не для всех проектов и нужны.
Приведите пример, пожалуйста, для чего нужны массивы в бизнес-логике платежной системы?
Да нет, я всего лишь к тому, что кривой код можно написать на чем угодно. И более того — большинство кривого кода написано не на языках хранимых процедур СУБД.
их трудно хранить в текстовых файлах
Чем?
кроме hibernate есть много других orm, не столь тормозных и без костылей
ORM без костылей — это нонсенс просто из определения ORM. Просто потому, что маппинг множеств и отношений между множествами в объекты влечет кучу проблем. Всегда. Могу предложить ссылку на классику на эту тему.
каким боком orm может нарушить acid принципы в субд
Ну, конечно, ОРМ обеспечивает все буковки аббревиатуры гораздо лучше, чем сама СУБД.
у вас есть положительный пример использования бизнес-логики в базе данных
За последние четыре года я сделал как минимум три крупных проекта Мэйл.Ру, используя логику приложения в СУБД. В разных СУБД, надо сказать. И везде это было оправданно. И везде работает. Нагрузки — от сотен хитов в секунду до десятков тысяч.
С другой стороны, это всего 35-70 писем в неделю.
Хотя, видимо, это как повезет, поскольку лично мне падает от силы около 10 писем в неделю. Однако на мой ящик на собственном сервере падает в разы больше спама. Вот интереса ради даже посчитал: 770487 за неделю отфильтровал мой антиспам, который фильтрует сильно хуже мэйлового. При том, что ясчик на Мэйле сильнее засвечен.
Но эт так, лирика…
Интереснее другое — какого рода спам падает к вам?
Хтмл с кучей текста или с минимум текста и ссылкой на какой-нить укорачиватель?
Вы забыли.
А люди из Яндекса, Рамблера, ВКонтакте, Гугла постоянно помнят, что он есть…
О чем это говорит? =) Ну, наверное, о том, что Вы не работаете в этих уважаемых конторах.
Понятно.
А как считаете, сколько в сутки спам-писем падало бы в Ваш ящик без спам-фильтров?
И сколько из них должно отфильтровываться?
Только не в идеальном мире с искусственным интеллектом, а в нашем земном?
Да, можно. Платежи между пользователями, конечно же, есть.
Комиссия — полпроцента.
Насчет вывода — не-не, пользователь может вывести из системы всю сумму, которая будет на счету. Какая при этом будет комиссия — зависит от способа вывода. Официально через ДМР — 5%. Через вывод на виртуальную карту — 3% с копейками. Более экзотичные способы (их можно придумать, ага) — зависит от.
За замечания спасибо, передам «куда надо».
Если интересно прямо сейчас, вот ответы на большое количество вопросов по виртуальной визе на сайте банка, через которого процессим. Почему на них не дали хотя б ссылку на сайте ДМР — большой, большой вопрос, это да.
Про преимущества для пользователя расскажу со своей колокольни, благо пользуюсь.
Что важно для пользователя интернета в произвольной платежной системе?
— куча дешевых способов ввода
— куча способов вывести в что-нибудь полезное.
Если говорить о ДМР, то ввести можно не очень большим количеством способов — терминалы, инет-банкинг, пластиковые карты (как раз в заголовке — о 0% по вводу).
А вот с точки зрения вывода помимо обычных сотовых-провайдеров-телевидения (и покупки Visa Virtual, дающей доступ вообще к куче вещей, правда, уже без участия ДМР) Деньги Мэйла открывают для пользователя вход в кучу мэйловых проектов, включая большое количество игрушек. Понятное дело, что для кого-то это никакое не преимущество, но для очень большого количества пользователей, как видно из последних года-двух развития Рунета, это неоспоримый плюс.
На Мэйле стояла витрина.
А год назад сделали свою платежку
В общем, опять же — у меня хватает примеров хранения sql-кода в репозитории, когда заносятся или пакеты (если СУБД их поддерживает), или функции, сгруппированные в файлы на подобие пакетов (если СУБД не поддерживает пакеты).
При желании, можно извратиться как угодно. Вам самому не кажется странным, что вместо одной сущности — СУБД — у вас добавляется еще две: кэш и орм? Как же принцип K.I.S.S? =) Ну да ладно.
Продолжение спора, в общем-то, непринципиально, ага.
Я могу аргументировать каждое свое предложение.
А Вы?
Переменные — нужны.
Более того, переменные в большинстве известных мне языков программирования СУБД есть.
Массивы не везде, но не для всех проектов и нужны.
Приведите пример, пожалуйста, для чего нужны массивы в бизнес-логике платежной системы?
Чем?
ORM без костылей — это нонсенс просто из определения ORM. Просто потому, что маппинг множеств и отношений между множествами в объекты влечет кучу проблем. Всегда. Могу предложить ссылку на классику на эту тему.
Ну, конечно, ОРМ обеспечивает все буковки аббревиатуры гораздо лучше, чем сама СУБД.
За последние четыре года я сделал как минимум три крупных проекта Мэйл.Ру, используя логику приложения в СУБД. В разных СУБД, надо сказать. И везде это было оправданно. И везде работает. Нагрузки — от сотен хитов в секунду до десятков тысяч.
Перефразирую: «Взаимодействие кучи кривонаписанного кода приводило к трудноотлавливаемым багам».
Перефразирую: «Отсутствие возможности поООПить — ужасно».
Перефразирую: «Мне пофиг на производительность, ACID и прочую фигню. Да и с SQL у меня плохо».
А вот теперь фраза от меня: и слава святым!
2. Нормально спроектированная система в миграции не нуждается.
3. ОРМ — говно.
Хотя, видимо, это как повезет, поскольку лично мне падает от силы около 10 писем в неделю. Однако на мой ящик на собственном сервере падает в разы больше спама. Вот интереса ради даже посчитал: 770487 за неделю отфильтровал мой антиспам, который фильтрует сильно хуже мэйлового. При том, что ясчик на Мэйле сильнее засвечен.
Но эт так, лирика…
Интереснее другое — какого рода спам падает к вам?
Хтмл с кучей текста или с минимум текста и ссылкой на какой-нить укорачиватель?
А люди из Яндекса, Рамблера, ВКонтакте, Гугла постоянно помнят, что он есть…
О чем это говорит? =) Ну, наверное, о том, что Вы не работаете в этих уважаемых конторах.
А как считаете, сколько в сутки спам-писем падало бы в Ваш ящик без спам-фильтров?
И сколько из них должно отфильтровываться?
Только не в идеальном мире с искусственным интеллектом, а в нашем земном?
www.exler.ru/expromt/16-12-2005.htm
И куча других способов сделать то же самое.
И не только на Мэйле.
Веб 2.0.
Но вообще — что Вам даст список адресов?
По нему даже спам не разослать…