Вопрос на гипотетическом собеседовании

Вопрос на гипотетическом собеседовании

Интересно услышать мнение общественности по следующему вопросу заданом на одном гипотетическом собеседовании.
Имеется инет магазин с хорошей посещаемостью к примеру 10000 человек в сутки, в магазине имеется скажем 10000 групп товаров и в каждой группе 100000 товаров. Нужно построить дерево товаров.

Таблица групп имеет скажем следующую структуру:
CREATE TABLE groups (
id int(10) unsigned primary key,
name varchar(255)
)

Таблица товаров имеет следующую структуру:
CREATE TABLE prods (
id int(10) unsigned primary key,
group_id int(10) unsigned not null,
name varchar(255)
)

group.id=prods.group_id

- Способ номер один, извлечь из базы все группы (группы в таблице групп уникальны) следующим запросом "SELECT * FROM groups" и на основании равенства id=group_id, где group_id есть идентификатор принадлежности товара определённой группе, извлекать товары принадлежащие каждой группе в цикле т.е. получиться 10000 обращений к таблице товаров.

- Способ номер два, извлечь сразу все группы и все товары следующими запросами:
"SELECT * FROM groups ORDER BY id" и
"SELECT * FROM prods ORDER BY group_id"
Результаты выборки первого селекта будут скажем в переменной $groups, результаты второго селекта в $prods.
И в обоих переменных будут двумерные массивы, где первый индекс будет индексом строки, второй индекс номером столбца.
И предлагается строить дерево в цикле примерно следующим образом:
<?php

$id=$id_2=0;
for ($i=0; $i<count($prods); $i+=3) {
if ($id!=$prods[$i]['group_id']) {
$id=$prods[$i];
$id_2++;
@$tree.=$group_id[$id_2]['name'].'начало новой группы в дереве';
} else {
@$tree.='добавление товара в дерево';
}
}

?>

Не вооружённым взглядом виден недостаток первого способа, слишком много обращений к табице товаров т.к. для каждой группы потребуется отдельное обращение к таблице товаров, групп у нас 10000 и именно это количество обращение и будет произведенно к таблице товаров при постройке дерева.
Недостаток второго способа в следующем, из БД извлекаются все группы одним запросом и товары тоже одним запросом т.е. будет иметься двумерный массив групп с размерностью 10000 по первому индексу и 2 по второму, так же будет иметься массив товаров с размерностью 100000 по первому индексу и 3 по второму.

Что общественность думает, какой способ лучше? Или может кто-то подскажет какое либо более удачное решение?
 
SiMM Может и бред, но вопрос такой был задан...
Будет ли вообще какой либо из приведённых способов практически работать при таком объёме товаров/групп и кол-ве посещений? Сможет ли php скрипт при такой посещаемости обработать объём информации из варианта 2?
 

CMHungry

Guest
а не проще объединить два запроса в один?
select g.*, p.* from prods p inner join groups g on (g.id = p.group_id) order by g.id, p.name
и получить один массив, из которого и пытаться сделать дерево?

К тому же, массив можно не вытаскивать весь в php, а по записи. Изменение g.id будет означать, что началась новая группа.

Но это не дерево получается, а так... список групп с товарами. Дерево - это когда группы могут быть вложенные друг в друга.
В таком случае так редко делают, потому что даже по массиву потом построить дерево - не шибко тривиальная задача, много проходов делать придется. На mysql это одним запросом не решается, на оракле - легко.
 
Автор оригинала: CMHungry
а не проще объединить два запроса в один?
select g.*, p.* from prods p inner join groups g on (g.id = p.group_id) order by g.id, p.name
и получить один массив, из которого и пытаться сделать дерево?
Этот запрос вернёт массив ещё большего размера чем размер массива товаров из способа 2...

К тому же, массив можно не вытаскивать весь в php, а по записи. Изменение g.id будет означать, что началась новая группа.
Т.е. Вы предлагаете в цикле обращаться к mysql к примеру с помощью функции mysql_fetch_array и в этом же цикле строить дерево?
Если да, то чем этот способ лучше/хуже приведённых выше учитывая большую посещаемость ресурса в сутки?

Что общественность думает какой способ будет оптимальным первые два приведённые мной или три приведённый CMHungry?
 

SiMM

Новичок
безграмотный, бред какой-то относилось к тому, что я написал поначалу. Что касается дерева - нет у тебя никакого дерева, как заметил CMHungry. И вообще в поставленной задаче непонятен смысл вопроса

> Сможет ли php скрипт при такой посещаемости обработать объём информации из варианта 2?

Ты что же это, предлагаешь каждому из 10000 по каждому запросу скачивать себе HTML-файл, содержащий 10000 групп товаров и в каждой группе 100000 товаров? А пупок, простите, у них не треснет? Качать такую массу информации на диалапе - дело не одной недели, да и с финансовой точки зрения - не копеек стоит.
 
Автор оригинала: SiMM
безграмотный, бред какой-то относилось к тому, что я написал поначалу. Что касается дерева - нет у тебя никакого дерева, как заметил CMHungry.
Я вчера был на собеседовании в одной известной инет.компании и раз они сказали, что это называется деревом значит так оно и есть :)

И вообще в поставленной задаче непонятен смысл вопроса
Вопрос в том какое решение является оптимальным 1, 2 (приведённые мной) или 3 приведённое CMHungry

> Сможет ли php скрипт при такой посещаемости обработать объём информации из варианта 2?

Ты что же это, предлагаешь каждому из 10000 по каждому запросу скачивать себе HTML-файл, содержащий 10000 групп товаров и в каждой группе 100000 товаров? А пупок, простите, у них не треснет? Качать такую массу информации на диалапе - дело не одной недели, да и с финансовой точки зрения - не копеек стоит. :D
Опять же предлагаю не я, это вопрос с собеседования :)
 

SiMM

Новичок
безграмотный, а тебе не приходило в голову, что это вопросы на засыпку? На таких вопросах легко валить новичков - грамотный специалист уточнит ТЗ.
 

Alexandre

PHPПенсионер
[sql]CREATE TABLE groups (
id int(10) unsigned primary key,
name varchar(255)
)[/sql]
здесь деревом групп и не пахнет - все группы линейные ;)

Нужно построить дерево товаров
как видно - в группе только могут быть только товары (но не подргуппы товаров), и группы могут быть пустые (без товаров)
 
SiMM Если бы это было так собеседующие не стали бы показывать, каким спообом они бы решили поставленную задачу...

Хорошо, изменим терминологию пусть то, что называлось выше деревом будет называться списком групп и товаров в этих группах.

Есть у какого нить соображения какой способ оптимальнее использовать?
 

Long

Новичок
безграмотный неужели за 12 часов, после первого поста, ты не смог написать 3 теста, которые дадут тебе ответ на твой вопрос?
 

Alexandre

PHPПенсионер
10 000 групп товаров и в каждой группе 100 000 товаров
тогда общее кол-во товаров будет 10 000 * 100 000 = 1 000 000 000
муська точно сдохнет при посещаемости в 10 000, это где-то
2-3 запроса в сек, а в час-пик где-то может достигнуть до 20

И в обоих переменных будут двумерные массивы, где первый индекс будет индексом строки, второй индекс номером столбца
получится массив из 1 000 000 000 элементов, и сервер сдохнуть может от использования такого объема массива....

в общем, безграмотный надо ставить задачу по иному.
 

SiMM

Новичок
> Есть у какого нить соображения
Есть. На месте работодателя - не брать тебя на работу :)
 

syfisher

TDD infected!!
На самом деле большое количество записей - это в принципе не проблема, если у вас результат запроса реализован не в качестве массива, а в качестве итератора. Тогда можно значительно сэкономить и на памяти и на выборке.

Если имплементить итератор, то можно применить и первый вариант, и второй - все зависит от конкретной задачи и наличиев навыков программиста.
 
Автор оригинала: SiMM
> Есть у какого нить соображения
Есть. На месте работодателя - не брать тебя на работу :)
У меня в свою очередь есть следующее соображение, не сотрудничать с работодателем который настаивает, что поставленная задача должна решаться способом номер 2 и никак иначе...

-~{}~ 04.03.05 15:14:

syfisher При использовании итератора в теле класса будет применяться один из приведённых выше способов
 

SiMM

Новичок
> У меня в свою очередь есть следующее соображение, не сотрудничать с работодателем который настаивает, что поставленная задача должна решаться способом номер 2 и никак иначе...

Если ты о своём гипотетическом работодателе - так и не сотрудничай, в чём дело то? Выбор за тобой :)

Если же это намёк на меня - то моё мнение озвучил Alexandre
 

Screjet

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

Alien

Новичок
безграмотный
На самом деле это вопрос "что лучше грузить - БД сервер или аппликейшен сервер".

У меня в свою очередь есть следующее соображение, не сотрудничать с работодателем который настаивает, что поставленная задача должна решаться способом номер 2 и никак иначе...
Вдумайся в магию цифр. 10000 запросов. Оцени время которое БД будет их переваривать.
 
Alien Именно так и стоит вопрос, но сервер БД 10000 запросов возможно рано или поздно переварит ещё до истечения времени исполнения скрипта, а вот сможет ли аппликейшен сервер вообще такой объём обработать большой вопрос и что-то мне подсказывает, что не сможет. Допустим описание каждого товара будет занимать в среднем 1 кбайт это будет 10,000*100,000*1 кбайт = 1000 гигов информации, не думаю, что на аппликейшен сервере будет стоят в настройках разрешение php скрипту использовать 1 терабайт оперативы...
 
Сверху