Что под серверной платформой понимаете? Очень уж общий вопрос.
JSON удобен.
Как показала разработка, пакеты данных в ПС весьма просты — обычно простой хеш, без всяких вложений. В принципе, раз данные простые, можно было бы и какой-то бинарный формат использовать для еще более быстрого парсинга данных, но все же
а) встречаются и более сложные структуры пакетов.
б) проще интегрироваться со сторонними сервисами, сейчас часто достаточно JSON-информацию от них включить в пакет системы практически без обработки. А делать библиотеки для работы со своим бинарным форматом под кучу платформ — увольте. XML, конечно, тоже можно юзать, но в целом сравнение скоростей наших либ для работы с XML и JSON оказалось не в пользу первого.
На момент старта проекта в августе этого года такой возможности не было.
Однако есть возможность оплачивать товары и услуги магазинов, подключенных к системе, с помощью тех же самых вебманей (и ряда других электронных валют). Без комиссии.
Пока же я вижу подростковые вопли «у нас нет php» но у нас есть PDF — извините, я на это не куплюсь.
Вы, видимо, подумали, что этот пост — пресс-релиз.
И ошиблись. Пресс-релиз на Хабре выходил месяц назад, а это — запись в личном дневнике.
Теперь ответы на Ваши вопросы с точки зрения человека, уже пользующегося системой (а не разработчика).
Если Вы выскажете мне реальные преимущества
Чтобы понять преимущества любой платежной системы, нужно обратить внимание на следующие моменты:
— удобство ввода денег.
— удобство вывода (в том числе число сервисов и магазинов, услуги и товары которых можно оплатить через эту ПС).
— размер комиссии за платежи
— размер аудитории
Рассмотрим подробнее каждый пункт
1. удобство ввода
Есть терминалы ОСМП (но это существенная комиссия). Их много.
Есть банковские платежи (тут только комиссия банка)
Нет пополнения через скретч-карты и кредитные карты.
В целом, ввод денег в систему затруднен.
Это минус. Есть один нюанс, о нем ниже.
2. удобство вывода
Вывести можно (если Вы гражданин РФ), но не моментально.
Набор магазинов стандартный — сотовая связь, интернет итп. Но не очень большой.
Нет вывода на карту.
Опять скорее минусы, чем плюсы.
3. размер комиссии
Тут уже лучше.
Комиссия на переводы между пользователями ниже чем в Вебманях, такая же как в Яндексе.
Комиссия на оплату сервисов — 0%
Комиссия на оплату товаров в подключенных к системе магазинах (например, МиниИгры на Мэйле) — 0% Но самое главное — система позволяет оплачивать товары и услуги подключенных к ней магазинов с помощью электронных средств других ПС: тех же WM и ЯД. И комиссия за такие платежи — 0%
То есть, теперь не надо сначала менять в обменниках WMR на ДМР, выплачивая комиссию в 3–5%.
Можно сразу без комиссии оплатить имеющейся у вас валютой.
Это плюс, на мой взгляд.
4. Размер аудитории
Размер аудитории влияет на возможность совершения платежей между пользователями.
Наверняка, Вы сталкивались с ситуацией, когда надо кому-то заплатить, а он принимает только ЯндексДеньги, которых как назло сейчас у вас нет.
Размер аудитории ДМР сейчас, понятное дело, маленький — проекту месяц. Но потенциал роста этой аудитории весьма и весьма велик, всё таки аудитория Мэйла — десятки миллионов человек.
Это плюс.
Итого, на мой взгляд у ДМР сейчас два плюса и два минуса.
Однако минусы можно пока списать на то, что система еще очень и очень юна.
Тот же Яндекс сделал возможность моментального вывода на банковский счет спустя годы после запуска ЯДов.
Стоит вернутся к вопросу о плюсах и минусах эдак через год.
Думаю, ситуация уже изменится в лучшую сторону.
Ну а выбор пользоваться системой или нет в любом случае за Вами.
«Партнерский проект» — это значит «не полностью свой, а совместный с партнерами».
А теперь полностью свой, судя по всему.
По-моему, изменения кардинальные :-D
Эт как у Яхи — раньше был свой поиск, а теперь будет партнерский с Микрософтом.
вместо выставления прав доступа к процедурам выставить их на таблицы/колонки
Мускул не позволяет устанавливать права на колонки. Выставление прав на таблицы ничего не даст, поскольку всё равно должен быть юзер, как-то их модифицирующий. Написание процедуры, инкапсулирование в ней работы с нужными таблицами и колонками значительно снижает возможности по случайной или намеренной модификации данных.
подумать, может вообще не стоит разделять права пользователей A и B, а вместо этого ввести некую роль (аккаунт R), которым будут пользоваться оба пользователя
Какая разница? Имеем то же самое.
если уж использовать эти хаки, то хотя бы автоматизировать их применение
А кто сказал, что автоматизация не используется?
Автоматизация описанного не относилась к теме данной статьи.
сделать две процедуры
Подход имеет право на существование, но
1. вдвое увеличит количество функций проекта.
2. при первой же необходимости изменить набор параметров процедуры или их типы приведет к описанной в статье проблеме.
В общем, как я писал выше — могли бы не продолжать, если не занимались предметной областью.
подробности реализации могут быть самые разные
Пока я не услышал ни одного конструктивного предложения, кроме банального — автоматизации описанного мной процесса.
Но любой другой вариант будет лучше этих хаков
К сожалению, пока я не знаю ни одного нормального варианта в рамках MySQL, который бы помогал избежать хака. Был бы — я бы только радовался, поскольку не пришлось бы изобретать эти хаки.
Описанный хак — он от бессилия перед немощью Мускула.
Ну если брать для сравнения мускул, то да, нужно радоваться успехам постгреса.
Хотя фраза «Although PostgreSQL supports cursors, they have not been used in the current implementation» не обещает легкой жизни.
Хотя да, МТС позволяет оплатить телефон кредиткой вообще не используя банк.
Правда, процессит кридитки не через банк, а через агент — Хронопэй.
JSON удобен.
Как показала разработка, пакеты данных в ПС весьма просты — обычно простой хеш, без всяких вложений. В принципе, раз данные простые, можно было бы и какой-то бинарный формат использовать для еще более быстрого парсинга данных, но все же
а) встречаются и более сложные структуры пакетов.
б) проще интегрироваться со сторонними сервисами, сейчас часто достаточно JSON-информацию от них включить в пакет системы практически без обработки. А делать библиотеки для работы со своим бинарным форматом под кучу платформ — увольте. XML, конечно, тоже можно юзать, но в целом сравнение скоростей наших либ для работы с XML и JSON оказалось не в пользу первого.
Понятное дело, кое-что рассказать я не смогу, но на некоторые вопросы, возможно, отвечу.
Хе-хе.
В целом, в регионах с интернет-банкингом и оплатой кредитками не так просто, как в Москве, Питере и ряде крупных городов России.
Страшно далеки Вы от народа, батенька ©
А вот интернет-аудитория из регионов уже несколько лет как больше интернет-аудитории МиП.
Однако есть возможность оплачивать товары и услуги магазинов, подключенных к системе, с помощью тех же самых вебманей (и ряда других электронных валют). Без комиссии.
Что будет в ближайшее время — поживем-увидим.
Впрочем, выше я ответил более подробно. Гораздо более.
Или так, «в лужу пёрнуть» пришел?
Вы, видимо, подумали, что этот пост — пресс-релиз.
И ошиблись. Пресс-релиз на Хабре выходил месяц назад, а это — запись в личном дневнике.
Теперь ответы на Ваши вопросы с точки зрения человека, уже пользующегося системой (а не разработчика).
Чтобы понять преимущества любой платежной системы, нужно обратить внимание на следующие моменты:
— удобство ввода денег.
— удобство вывода (в том числе число сервисов и магазинов, услуги и товары которых можно оплатить через эту ПС).
— размер комиссии за платежи
— размер аудитории
Рассмотрим подробнее каждый пункт
1. удобство ввода
Есть терминалы ОСМП (но это существенная комиссия). Их много.
Есть банковские платежи (тут только комиссия банка)
Нет пополнения через скретч-карты и кредитные карты.
В целом, ввод денег в систему затруднен.
Это минус. Есть один нюанс, о нем ниже.
2. удобство вывода
Вывести можно (если Вы гражданин РФ), но не моментально.
Набор магазинов стандартный — сотовая связь, интернет итп. Но не очень большой.
Нет вывода на карту.
Опять скорее минусы, чем плюсы.
3. размер комиссии
Тут уже лучше.
Комиссия на переводы между пользователями ниже чем в Вебманях, такая же как в Яндексе.
Комиссия на оплату сервисов — 0%
Комиссия на оплату товаров в подключенных к системе магазинах (например, МиниИгры на Мэйле) — 0%
Но самое главное — система позволяет оплачивать товары и услуги подключенных к ней магазинов с помощью электронных средств других ПС: тех же WM и ЯД. И комиссия за такие платежи — 0%
То есть, теперь не надо сначала менять в обменниках WMR на ДМР, выплачивая комиссию в 3–5%.
Можно сразу без комиссии оплатить имеющейся у вас валютой.
Это плюс, на мой взгляд.
4. Размер аудитории
Размер аудитории влияет на возможность совершения платежей между пользователями.
Наверняка, Вы сталкивались с ситуацией, когда надо кому-то заплатить, а он принимает только ЯндексДеньги, которых как назло сейчас у вас нет.
Размер аудитории ДМР сейчас, понятное дело, маленький — проекту месяц. Но потенциал роста этой аудитории весьма и весьма велик, всё таки аудитория Мэйла — десятки миллионов человек.
Это плюс.
Итого, на мой взгляд у ДМР сейчас два плюса и два минуса.
Однако минусы можно пока списать на то, что система еще очень и очень юна.
Тот же Яндекс сделал возможность моментального вывода на банковский счет спустя годы после запуска ЯДов.
Стоит вернутся к вопросу о плюсах и минусах эдак через год.
Думаю, ситуация уже изменится в лучшую сторону.
Ну а выбор пользоваться системой или нет в любом случае за Вами.
Стало понятнее?
К каковым относится Бейсик.
Да, повод.
Если зайти на games.mail.ru/mini можно найти раздел «Пополнить счет»
Так вот там есть и Деньги.
А вот почему пока нет на самом сайте — да, вопрос интересный.
А теперь полностью свой, судя по всему.
По-моему, изменения кардинальные :-D
Эт как у Яхи — раньше был свой поиск, а теперь будет партнерский с Микрософтом.
А знаете, что скажет ему менеджер, когда программист потеряет гранты на какие-то процедуры, используемые в 24x7 проекте?
Буду только рад, если кто-то мне подскажет эти подходы. Серьёзно.
К сожалению, изучение документации особо не помогло.
Если требование рабочего процесса — использование хранимых процедур, как прикажете его изменить?
Пастернака не читал, но осуждаю. ©
Дальше могли бы не продолжать в таком случае.
Мускул не позволяет устанавливать права на колонки. Выставление прав на таблицы ничего не даст, поскольку всё равно должен быть юзер, как-то их модифицирующий. Написание процедуры, инкапсулирование в ней работы с нужными таблицами и колонками значительно снижает возможности по случайной или намеренной модификации данных.
Какая разница? Имеем то же самое.
А кто сказал, что автоматизация не используется?
Автоматизация описанного не относилась к теме данной статьи.
Подход имеет право на существование, но
1. вдвое увеличит количество функций проекта.
2. при первой же необходимости изменить набор параметров процедуры или их типы приведет к описанной в статье проблеме.
В общем, как я писал выше — могли бы не продолжать, если не занимались предметной областью.
Пока я не услышал ни одного конструктивного предложения, кроме банального — автоматизации описанного мной процесса.
К сожалению, пока я не знаю ни одного нормального варианта в рамках MySQL, который бы помогал избежать хака. Был бы — я бы только радовался, поскольку не пришлось бы изобретать эти хаки.
Описанный хак — он от бессилия перед немощью Мускула.
Подробнее может напишу позже. Как раз недавно сравнивал Мускул, Постгресс и Оракл.
Хотя фраза «Although PostgreSQL supports cursors, they have not been used in the current implementation» не обещает легкой жизни.
Нормальная работа с курсорами, анонимными блоками и так далее.