LLIAKAJI, покажи свой запрос которым ты вибирал строку из базы, когда в первом посте писал о эксперементах


_____________
Стимулятор ~yoomoney - 41001303250491

tovar(id_tovara, name);
pokupan(id_pokupana, name);

zakaz(id_tovara, id_pokupana);

/* выбрали все заказы покупана */
select * from zakaz where id_pokupana = $user_id;

/* выбрали всех покупанов данного товара */
select * from zakaz where id_tovara = $prod_id;

/* чтобы вывести все что есть 
соединенное соответственно таблице заказов 
кроме нее самой: */

select pokupan.* , tovar.*
  from zakaz 
  join pokupan 
    using(id_pokupana) 
  join tovar 
    using(id_tovara);

Если все сделано нормально, последний запрос вырождается в форму

select *
from zakaz 
natural join pokupan
natural join tovar

Потому что zakaz может содержать полезную инфу, как то дата заказа, количество, комментарии, но после натурального джойна колонки pokupan_id и tovar_id не окажутся размноженными как при обычном джойне через ON.

Да, кстати, откуда у ТС берутся не уникальные покупатели? Это количество товара, не иначе. ЧТобы заказать 5 надо 5 раз заказать.

Реляционные субд не любят тупых и ленивых пользователей. Таких они карают чудовищными процедурами в скриптах.

Материльно надо показать. В таблице заказов будет примерно так

id_tovara ; id_pokupana

1 ; 9
4 ; 9
5 ; 5
6 ; 9
7 ; 14
12 ; 10
5 ; 14
7 ; 9
88 ; 5
1 ; 4

select * from zakaz where id_pokupana = 9

получаем: 1, 4, 6, 7 - вот что заказал покупан номер 9

select * from zakaz where id_tovara = 5;

получаем: 5, 14 - вот кто заказывал подарочный набор для пупка: щеточка для чистки, мех для холодной погоды и бриллиант для торжественных случаев.

Такие таблицы называются отношение N:N.

ТС сидя на унитазе хочет вывести покупанов из таблицы товаров. Пыткой с особой жестокостью станет попытка удалить выполненный заказ покупана. Придется достать всю строку, разбить, удалить элементы, соединить, записать обратно.

Другими словами оператора DELETE у него вообще не будет. Удаление реализуется в недрах скрипта, в субд шарашат только UPDATE.

А вот как если все нормально:

delete from zakaz where id_pokupana = $user_id.

Все заказы покупана удалены. Когда таблица заказов обогащена дополнительными полями условие гибче

delete from zakaz where id_pokupana = $user_id AND initial_date = $selected_date;

Удалили заказы покупана которые он сделал в прошлой $selected_date.

Внезапно подарочные наборы для пупка кончились и поставок не предвидится

delete from zakaz where id_tovara = 5;

Все, нет ни у кого в заказах миленького наборчика. Есть повод сделать рассылку с извинениями. Кому? Тем кого вернет запрос выше, а именно

select * from zakaz where id_tovara = 5;

сделанный до удаления, ессно.

Да, для интерфейсов и операторов можно предусмотреть еще поле zakaz_id с автоинкрементом. Что позволит обновлять и удалять записи в таблице заказов мануально или хиропрактически, вручную, короче. Безотносительно к отношению. Просто не понравился этот заказ оператору, он его чпок и удалил по ид заказа.

Разошелся, блин... в общем ТС, сидя на унитазе халявы вы теряете деньги. Получить деньги вы могли бы предложив заказчику такие плюшки как подсчет и анализ.

Например что у нас не заказывают? Группируем заказы по ид товаров в свободном отношении, то есть LEFT JOIN. Все товары которых никто не заказывал отношения не имеют и вы увидите NULL.

Что у нас заказывают больше всего? Группируем с подсчетом и сортировкой DESC. Получаем рейтинг популярности.

И самое интересное. Кто у нас заказывает и чего больше всего? Под словом "кто" подразумевается не ид, а счет юзера в социале. Где он про себя любимого все рассказал.

Уловив интерес вы можете выставлять такому покупателю индивидуальную цену. Вот где деньги.

Конечно-конечно, все можно сделать в процедурах. Засосать всю таблицу товаров, разобрать ее по косточкам и с упоением ковыряться в массивах. Но тогда на кой член вообще БД?