Всем доброго времени суток. Вот появился такой вопрос, подскажите пожалуйста кто сможет? Собираюсь создавать сам, если конечно терпения хватит, что то вроде системы заказов, пользователь составляет заказ из формы, отправляет, заказа заноситься в БД mysql, у заказа далее будет несколько статусов, ну например, оплачен, не оплачен, ожидает оплаты и в таком духе. Вопрос: как правильно спроектировать БД, чтобы потом проще было назначать определленный статус заказам? Не пойму, для каждого заказа необходимо делать отдельную таблицу, и по мере изменнеия статуса заказа, переписывать данные заказа из одной таблицы в другую. либо есть какой то другой способ? Всем заранее большое спасибо за ответ.
Да, более правильный способ есть. Возможно, тут даже найдутся добровльцы, которые смогут это обьяснить достаточно коротким текстом. Возможно - прийдется самому читать книги по проектированию баз данных.
Artur2006 Пиши всё в одной таблице. Я думаю, у тебя в основном все поля будут у всех заказов значимые, а разница будет лежать лишь на статусе. В большинстве случаев на этом всё заканчивается. Есть варианты делать, для каждого статуса свою таблицу, но запросы могут быть медленнее в таком случае, хотя частота блокировок может быть меньше. Конечно это зависит от того что твои статусы будут тебе давать, и как ты хочешь ими оперировать. Почитай про Table Inheritance (Single, Concrete и Class) а также про Inheritance Mappers. Эти шаблоны могут тебе помочь правильно подобрать структуру БД.
Можно немного подробнее, что значит значимые? Я вот думаю так. Если писать данные заказа в одну таблицу. встает вопрос. как средствами php назначать заказ? подскажите пожалуйста? :roll:
Вспе ясно, я та понял. нужн овсе пробовать на конкретном примере. ну скоо покажу, если что то получиться? Всем спасибо, если вы можете еще что то добавить, с радостью выслушаю.
Можно подглядывать в качестве примеров. http://www.databaseanswers.org/data_models/index.htm Но использовать в реальной работе не рекомендуется.
Ну не, думал думал, а как все же начать, так и не додумался, ну подскажите пожалуйста, делать отдельные таблицы для каждого статуса. или как можно по дргугому средствами php назначать статус для данных заказа?
Таблица заказов содержит данные о заказе и поле "status", в котором указан id статуса. Статусы хранятся в другой таблице, в которой минимум id и имя статуса. При выборке заказов используешь JOIN. При смене статуса у заказа делаешь UPDATE поля "status".
Мило в теории, но на практике не работает. Кстати, я люблю этот пример давать как раз, что бы теоретиков от практиков отличать. Немного подумав, можно понять, почему это не работает на практике.
Подскажите тогда более реальный пример, хотя выше предложенный я так понимаю, выглядит нормально, но почему не работает, хотелось бы узнать? Если не трудно, расскажите пожалуйста?
В целом, пример правильный. Но поработав с магазином, выясняется, что под "сменой статуса заказа" часто оказывается смена адреса доставки, например. А это плохо впихивается целочисленные идентификаторы как таковые. Однако самой большой ошибкой оказывается, когда в поле заказа пихают артикул (ид) товара - тогда у клиента все шансы получить товар не по той цене, по которой он покупал, а по той, которая была на момент отгрузки со склада.
Пример использовался на практике. И использовали его только для указания состояния заказа - покупатель мог залогиниться в магазин и посмотреть на какой стадии обработка его заказа, а варианты вроде "смена адреса доставки" думаю разумнее решать по телефону
лол. я работал с инет магазином, где 15 человек курьеров и 3 склада. КАК они узнают, что сменился адрес доставки?
Народ, а может кто за деньги сделает тз есть, но мне бы хотя бы часть того, что там, самые главные функции реализовать, некоторые пока можно опустить. Скажите, кто за сколько возметься? вот тз http://slil.ru/28581009 Ну это я так. может у кого появиться желание поработать для души, ну не бесплатно конечно. А то у меня за эти дни голова распухла, от думак. плохо, когда хочешь сделать, но не знаешь, с какой стороны вообще к этому подойти.
Смена статуса заказа - это именно смена статуса (не оплачен, оплачен, отгружен, в пути, принят, отменен) Если вдруг в заказе меняется цена, адрес, а не дай бог клиент или товар. Это новый заказ. Омг, и как ты решил этот вопрос? Курьер взял пицу и поехал. Он еще не доехал, но в заказе пица изменилась на торт, да и адрес стал другим. И чего делать?
Не, ну вот, создатель темы отдыхает в углу, наблюдая прения сторон, а стороны как обычно разделились на разные фронты. Забыли про меня?
Artur2006 блин не пакуй тз в док файл. Upd: Мда, ТЗ написано сумбурно, но с размахом. От 2 до 4 недель работы. Причем безоператорную интеграцию внутренней платежной системы с Банк и Почтовый перевод я вообще представляю себе крайне смутно (нет, в сделать это можно, но весьма недешево.)