История на поръчките част 2

teroristd

Registered
Здравейте, това е продължение на предишната тема.
@raiden беше така добър да предложи помощта си, за правилното изграждане на базата и реализацията на задачката.

Първо ще обясня какво точно искам да постигна, и след това ще пусна sql-a. Задачката се състои от две части.

Първа и по-важна част е администраторската.
Искам администратора да вижда всички направени поръчки, като всяка поръчка трябва да съдържа цялата информация за нея. Например снимка на предмета, цена, адрес за доставка и т.н. Ако поръчката съдържа повече от един предмет, съответно да излизат един под друг и да се смята обща цена. Всяка една поръчка да има статус, например за нова поръчка - обработва се, когато бъде изпратена - изпратена и накрая приключена. Това трябва да се прави от администратора, може би чрез някакви бутони към самата поръчка. В таблиците още не съм сложил полета за статусите. Принципно е добре да може поръчките да се визуализират по статуса. Нови, изпратени и приключени. Мисля че не е зле и да може да се изтриват.

Втора част е за потребителите.
Тук е по-просто. Потребителите да виждат поръчките си, също и статуса. В тази част мисля да се визуализират до пет поръчки назад. Един вид когато потребителя направи шеста поръчка, първата да бъде изтрита.

Пускам таблиците, като особеното е че съм ги разделил в три бази данни. Едната няма общо с поръчките и може да се игнорира, но ще я пусна все пак да я има. Базата в която сe добавят предметите се казва admin, а таблицата offer.
 
Защо в orders има поле order_id?

В тази таблица трябва да има само ид на потребителя + продуктите.
Верно е мазало.
 
uphero каза:
Защо в orders има поле order_id?

В тази таблица трябва да има само ид на потребителя + продуктите.
Да. Като за начало може да махне цялата потребителска информация от orders и да държи само id-то на юзера, откъдето ще може да си извади допълнителни детайли:
[sql]
CREATE TABLE `orders` (
`id` int(11) NOT NULL,
`first_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, -- Тук
`last_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, -- Тук
`email` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, -- Тук
`image` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`sizes` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`counter` int(11) DEFAULT NULL,
`quantity` int(11) DEFAULT NULL,
`price` double DEFAULT NULL,
`address` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, -- Тук
`phone` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, -- Тук, и надолу ако има също
`sku` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`invoice` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`order_id` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

[/sql]
 
Аз не разбрах код ли искаш или структура?


Аз по код не ме бива много, ето ти линк за структура правилна :)

https://pastebin.com/xkG7u5A4
 
Най-лесно е да премахна всичко от orders и да оставя само email примерно, който е уникален за всеки юзър. Въпросът е каква трябва да е заявката/заявките?
 
Не знам колко голям ще ти стане проекта, но ако трябва да правиш някакви events календари и статистики или пък клиента да не иска да има задължителен email при поръчка или има бърза поръчка само по телефон и име и адрес какво правим.
Според мен е редно да се помисли за напред какво може да се изисква от проекта, защото ако излезе нещо и систематати не е измислена добре като структура....или греша?!
Ще се радвам да ме поправите защото още се уча на тези неща.
 
@teroristd съжалявам че се изгубих така и те оставих да висиш но нямам много време напоследък.

Направо по същество, като за начало orders съдържа данни от 3 таблици и трябва да се заменят с външни ключове.
Първо можеш да си направиш 1 таблица за поръчки с полета за клиент, датата на поръчката и например статуса
[sql]CREATE TABLE `orders_new`(
id int primary key auto_increment,
user_id int not null,
date_added timestamp default current_timestamp
);
INSERT INTO `orders_new`
select
distinct(o.order_id), u.id as user_id, null
from orders o
left join users u
on o.email = u.email;
[/sql]
orders_new: id INT, user_id INT, date_added TIMESTAMP ...

После трябва да направиш свързваща таблица между поръчките и продуктите
В момента нямаш поле което да идентифицира продукта така че ще ползвам картинката+цената
[sql]CREATE TABLE `orders-products`(
order_id int not null,
product_id int not null,
quantity int not null default 1,
price float(8,2) not null,
sizes varchar(60)
);
INSERT INTO `orders-products`
select
o.order_id, p.id as product_id, o.quantity, o.price, o.sizes as option
from orders o
left join offer p
on o.image = p.image and
o.price = p.price;[/sql]
orders-products: order_id INT, product_id INT, quantity INT, price FLOAT, option VARCHAR
Тук предполагам че логиката ти за размерите е в кода, макар че е добре ако имаш различни варианти на 1 и същ продукт да създадеш 2 нови таблици - 1 за видовете опции (размер, цвят и т.н.) и една която да свърза даден продукт с определени опции. Ако решиш да го правиш трябва да се вземат предвид групи опции (синя S и L, червена M и L) за които е добре да се направят още 2 отделни таблици.

Таблицата в която съхраняваш картинките към определен продукт има колона image_id, а до колкото виждам отговаря на offer.id, така че преименувай я да не те бърка. Полето offer.image можеш да го махнеш.

Съжалявам отново че нямам достатъчно време да продължа темата.
Oпитай се сам да изкараш категориите, размерите и цветовете в отделни таблици. Основното което трябва да знаеш са два типа връзки
1 към много - пример за това е връзката между таблиците offer и offer_images.
Имаш 1 продукт с много картинки, но 1 картинка е само за 1 продукт. Връзката се реализира като в таблицата с "многото" се включи колона (външен ключ) която посочва "едното". В твоя случай offer_images.image_id сочи към offer.id и посочва за кой продукт е картинката.
много към много - пример е връзката между offers и orders. 1 продукт може да участва в много поръчки и в 1 поръчка може да има много продукти. Реализира се с нова свързваща таблица (orders-products). Включват се външни ключове към първичните ключове на двете таблици (order_id->orders.id, product_id->offer.id). Двата атрибута могат да се използват като съставен първичен ключ или да се създаде нов.
Ето и за финал заявка която да сглоби ненормализираната таблица от новите:
[sql]select
u.first_name,
u.last_name,
u.email,
img.image,
op.sizes,
op.quantity,
op.price,
u.address,
u.phone,
p.sku,
o.id
from orders_new o
join users u on o.user_id = u.id
join `orders-products` op on o.id = op.order_id
join offer p on op.product_id = p.id
join (select image_id, max(image) as image from offer_images group by image_id) img on p.id = img.image_id[/sql]
Ползвам агрегатна функция, за да взема само 1 от няколкото картинки, така че може да се различава от оригиналната.
Ще се опитам да следя темата, ако имаш въпроси питай
 

Горе