Чтобы работать с Visa/MC напрямую, нужно всего лишь построить свой процессинг.
на сервисах виртуальных номеров, понятное дело
В таком случае, конечно, можно строкой хранить, но, честно говоря, появление таких вещей говорит о серьезных проблемах в проекте
И это хорошо, в базе надо корректные данные держать потому что.
Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.
Во-первых, у mysql и postgresql для таких данных есть специальное поле.
Не надо слушать малолетних незнаек из соседних ответов.
...
Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности.
Надо купить себе букварь по базам данных, прочитать его, чтобы такие глупости не приходили в голову.
Вы можете сказать и меньше и больше. Но желательно обосновать. Или вы балабол.
По объему ориентируйтесь от 3 месяцев, команда есть.
Я, устраиваясь в банк, честно в анкете написал ПДД-шные статьи КоАП.
Зашел в пару крупных интернет-магазинов продающих софт и спросил у них, а что же я получу вместе с покупкой электронного ключа за 9 или 11 тысяч. Таки шо вы думаете они ответили? — Вы на почту получите закрывающие документы, представляющие из себя просто электронный чек, речи же ни о каком дополнительном соглашении вроде того, которое вы упомянули, речи и нету, просто чек и усе + этот ключ.
в сё зависит от финансов. У стартапов обычно нет денег на старте, поэтому приходится делать "хоть как-то".
Я просто понял, что далеко не всё зависит от ЯП, а по большей части скорость зависит от БД
а дело не брошу, какое бы сложное оно не было
Я беру сказку и перевожу каждое слово в ней с анг.яз на русский
еще раз: техническая часть - это довольно несложная для квалифицированных разрабочиков.
как бы круто не звучало насчет "процессинг", но по факту там довольно просто всё (не для джуна, конечно).
львинная доля расходов - это именно формальная составляющая, а не сама разработка.