Есть файл livein.php внутри файла нужный скрипт, и функция echo, например в php сайте можно было бы использовать include, чтобы на странице потом показывало элементы что внутри livein.php, а как поступить с сайта где нету php ? я использовал для Googlerobots функцию $.getScript( ) а как вывести то что внутри livein.php я не знаю, как это сделать ?
Не совсем понятно.
Совсем нет PHP на сайте то есть не поддерживает его или есть всё таки?
Даже не мог предположить что так должно быть так как читал что при выборке из 2х таблиц с использованием JOIN используется заместо WHERE обозначение ON а что их вместе использовать в одном запросе можно даже не подумал.
$t ="SELECT * FROM `". DB_PREFIX ."history` JOIN `". DB_PREFIX ."operations` ON ". DB_PREFIX ."history.id_operation=". DB_PREFIX ."operations.id AND `id_seller`='%d' OR `id_agent`='%d' ORDER BY `date` DESC";
Вывожу всё в html с помощью mysql_fetch_assoc
И вот что получается когда заходит на страницу продавец id_seller то выводит все его операции нормально.
А вот когда заходит агент id_agent то выводит нужную запись и он её повторяет столько раз сколько записей в таблице operations
Записей в таблице history всего 5 и все они принадлежат одному продавцу id_seller и среди них в одной из записей есть id_agent которую он и должен вывести.
?
Если таблица большая, лучше один запрос + http://php.su/functions/?array_reverse
Извините но я почитал про array_reverse но тут информации очень мало на других форумах пиводят пример в циклу while и записывая в переменную но это мне не подходит дело в том что у меня полный пример.:
Да это кстати интересная мысль но хотелось бы всё таки узнать где лучше хранить большой обём информации в базе или текстовом файле?
И стоит ли создавать историю для каждого вида пользователя то есть: для ПРОДОВЦА, АГЕНТА, ЭКСПЕРТА, АДМИНА, или стоить просто как я и задумал разделить просто по ID участника?
Все зависит от того как часто вам будет нужно работать с этими данными и в каком виде. В принципе ваша база и так в любом случае должна хранить все данные по операциям платежным, по юзерам например в таблице юзеров, по заказам в таблице заказов по текущим операциям в другой таблице и т.д. вопрос в том стоит ли собирать эти же данные в отдельную таблицу для более простого быстрого извлечения.
Данные не должны дублироваться в рамках одной базы данных в двух разных таблицах. Хотите единые отчет - очень-много-табличный запрос.
Поэтому я просто все операции с платежами вел в виде отдельного текстового лога, создаваемого каждые сутки и удаляемого раз в месяц.
считываем данные с файла по примерному времени операции и говорим пользователю почему не прошел платеж (на самом деле это должно делаться автоматом, а лог-файл служит просто для удобного просмотра и работы с последовательностью операций в тех случаях когда не надо вносить изменения в бд). Реализовано в виде одного класса с методами записи отличающимися в зависимости от типа операции - оплата, возврат, запрос сервера платежной системы, приход статус успешной оплаты, запись ошибки оплаты и т.д.
Да вы правы в базе будет лучше сделать в моём случае и решил прислушаться к вашим словам и не скапливать повторяющуюся информацию и разделить на разные таблицы и вытаскивать нужные данные проверками и запросам тем более не так мого нужно будет вытаскивать.
Лично я не делал специальную таблицу в бд для хранения истории операций. Понятно что таблицы с заказами хранят даты статусы всех операций, связаны с таблицами пользователей и тд. Всю сводную историю всех операций с деньгами храню в едином лог-файле. Туда какраз и пишу, дату, айпи адреса, логины, контакты, ошибки, суммы типы операций и время. сюда же пишу все запросы серверов платежных систем о прохождении платежей и любых операций.
Да это кстати интересная мысль но хотелось бы всё таки узнать где лучше хранить большой обём информации в базе или текстовом файле?
И стоит ли создавать историю для каждого вида пользователя то есть: для ПРОДОВЦА, АГЕНТА, ЭКСПЕРТА, АДМИНА, или стоить просто как я и задумал разделить просто по ID участника?