Суть проблемы (и уже имеющаяся дискуссия) на http://phpclub.ru/talk/showthread.php?s=&threadid=109709 Главный вопрос -- ставили ли перед кем-либо подобные задачи и как они реализовывались(имею ввиду бизнес-логику приложение. остальное -- мелочи)? ps. отправлять читать Фаулера "Архитектура корпоративных программных приложений" не стоит
Пыщь-пыщь! В итоге значит как было сделано. Имеются 3 таблицы: prefix_orders (ордера), prefix_payments (платежи) prefix_orders_info (разного рода данные, введённые при заполнении анкеты на покупку), prefix_orders_shipments (выбранные способы доставки товара при покупке. Эти способы выбираются из тех, которые предоставил для выбора продавец, который в свою очередь выбирает из предоставленных на выбор администратором для выбранной рубрики). Структура таблиц: Ордеры. `cost` - стоимость ордера в рублях. sms_self_cost - себестоимость одного SMS сообщения на момент создания ордера а sms_extra_charge - стоимость, по которой SMS сообщение продаёт торговая площадка (т.о. мы сможем выдавать владельцу площадки и статистику по тому, сколько он заработал только на SMS сообщениях). RoboCRC и RoboCRC2, как вы можете видеть из типа поля, это md5 хэш, необходимый для сервиса Робокасса (универсальный пункт приёма электронных денег). Ну тут всё понятно - поле order_id для связи с таблицей ордеров, поле date зачем у меня там я не знаю, ибо оно есть в и shop_orders. Но это не особо важно. Хрен с ним В остальных полях - введённые данные пользователем. Соотношение один-ко-многим с таблицей shop_orders (для доставки выбранными способами покупателями). Собственно здесь всё просто - вся информация о платежах. В случае оплаты через сервис "Робокасса" в полях payer_purse и payer_wmid хранится значение "robox", т.о. я буду высчитывать процент оплат через робокассу и вэб-мани мерчант (как одна из частей модуля статистики, коим я начну заниматься через несколько дней). Вот как-то так. Получаю баланс я следующим образом: В псевдо-ячейке `balance` хранится баланс продавца в рублёвом эквиваленте. В псевдо-ячейке `roub` хранится html код обозначения символа рубля (т.о. он обозначается на всей территории площадки. Из админки в два клика "Руб" меняется на "Р.", например. Удобно). В случае вывода средств с торговой площадки в payments кладётся запись с отрицательным cost
Алярм!!! Не знаю на сколько ровно это работает, но тип float для приближенных вычислений. Т.е. даже если положит в базу число типа 4.5, select`ом возвращало фигню типа 4.49999. В некоторых приложениях нормально работало, но по сути это неправильно. Сам, кажется, использовал тип decimal.
Гость, omg, перечитал http://www.mysql.ru/docs/man/Numeric_types.html по вашей наводке. спасибо. да. вообще у меня багов в этом плане замечено не было, т.к. у меня при выводе\установке цены ордера используется округление до двух знаков после точки ну соответственно этот же метод исмпользуется в механизмах защиты системы при оплате (защита от подмены суммы, например). добавлено через 36 минут а вообще я так и не понял про какую такую аптечную точность вы писали. float - 3.00 / 3.7 = 0.81081081081081, чего и требовалось ожидать. Не знаю в каких случаях это может быть важным. добавлено через 12 часов 13 минут А долги продавца так рассчитываются (долги образуются в случае, если покупатели оплатили Н выпусков рассылки, к-е на данный момент не получили). добавлено через 12 часов 19 минут а, в вэре ещё дописать надо AND `o`.`subscribes_remain` > 0