$query=mysql_query("INSERT INTO orders(name,s_name,address,post_index,email,`date`,time,product,prod_id,price,qty) VALUES ('$name','$s_name','$address','$post_index','$email','$date','$time','{$product['title']}','{$product['id']}','{$product['price']}','$quantity')");
endforeach;
echo"<p align='center' style='color: #fff;'>Ваш заказ успешно принят! Спасибо за покупку!</p>";
Где-то видел подобную реализацию, если не ошибаюсь, то в джумле.
Хотелось бы узнать, как это называется?
И если не трудно, то показать простенький пример подобного класса.
Сидел, думал, много думал, потом еще подумал и еще, что-то реализовал, но в итоге не пришел к идеальной структуре таблиц в базе.
Сформировалась только такая картина:
При заходе в категорию, создается строка в таблице read_category
с такими данными id | cid | topics | posts | userid
cid - id прочитанной категории
topics - количество прочитанных тем(по умолчанию ноль). Вставляется значение по умолчанию
posts - количество ответов(по умолчанию ноль). Вставляется значение по умолчанию
При заходе в тему, создается строка в таблице read_topics
с такими данными id | tid | posts | userid
tid - id прочитанной темы
posts - количество постов в данной теме
id и userid думаю объяснять не надо
При просмотре списка категорий формируется запрос, который проверяет текущее кол-во тем и постов и сверяет их с данными в таблице read_category.
При просмотре списка тем формируется запрос, который сверяет текущее кол-во постов с постами в таблице read_topics.
Если данные не равны, выводит жирный шрифт, иначе обычный.
Всё вроде бы работает хорошо, но есть 2 проблемы - удаление и перенос(тем и/или постов).
При удалении поста, требуется обновить все поля в таблицах read_category и read_topics где tid = текущей категории поста, а если таких over 9999 строк? Что тогда?
То же самое и с удалением тем, но там надо при обновлении вычитать посты и делать -1 на топике.
А с переносом тем, там вообще провал, если подумать. +4 запроса, если не ошибаюсь.
Может подскажите правильную структуру формирования "Прочитано/Не прочитано"?
По тому что то, что я написал сейчас, немного напоминает мне касету с дешевым порно 90-х годов.
Занялся написанием статуса тем/категорий на форуме.
Подскажите, как организовать со стороны хранения данных?
Давно писал систему входящих/исходящих сообщений, там все было просто. Если у сообщения пользователя статус 0, то делаем sql апдейт на единичку, если единичка - игнорим.
В голову пока лезет только такая мысля:
1. Проверка прочитанного/непрочитанного топика
Проверяем, имеется ли кука read_topic содержащая id темы и кол-во постов в ней. Если да, название темы делаем тонким, иначе жирным шрифтом.
При заходе в тему, создается кука read_topic, если ее еще нет, а если есть и кол-во сообщений не равно текущему кол-ву сообщений в теме, обновляем значение куки.
Ну а далее с проверками категорий я просто запоролся.
Подумываю о хранении в mysql, но со стороны ресурсов - это вообще не выгодно, но возможно я ошибаюсь и есть хорошее решение.
И вот еще момент, при нажатии на нужную категорию, например "Комедии" -> выводятся все материалы относящиеся к этой категории, у меня есть таблица "files" - в ней информация о файлах содержится, categories - таблица с категориями, я пытался сделать таблицу "file_cat" в ней как бы должна быть связь категорий с файлами (поля "id|file_id|cat") - не знаю так или нет делал (со связью) в общем ничего не получается, скажите как правильно
Для поля "cat" использовать IN и проверять наличие категории в массиве
EuGen, да, прошу прощения. Результатом будет (если искать ключевое слово из таблицы posts) - тема. А если искать по таблице topics, то результатом по прежнему будут все посты из темы.
Это происходит из-за `p`.id AS pid(проверил). В результате того, что в таблице topics просто нет поля pid, запросы видирает все из таблицы posts с данным tid.
Мне же нужно получить, либо идентификатор поста(ов)(p.id) и темы(tid), либо только темы(t.id) (Добавление)
Просто не хочется делать, что-то на подобии "Расширенного поиска" с поиском только по таблице posts или по таблице topics
Я уже изначально накосячил, сделав две отдельные таблицы с постами и темами, хотя правильней было-бы все хранить только как посты