-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
С.
Guest
Коль у тебя сквозная кодировка по подкатегориям, то вот здесь и есть принципиальное нарушение структуры данных. Из этого вытекает и твоя основная проблема с выборкой по категории.
Если бы было, как положено в идеале (кодировка подкатегории ведется в каждой категории изолированно), то и не возникло бы проблемы. Ты съэкономил на одном, но потерял в другом. Если уж выбирать, где заморачиваться, то я выбрал бы вариант, который больше отвечает теоретическим принципам, даже если там надо кодировать чуть больше. Не известно, какие еще могут задачи встать впереди, а так есть шанс, что они решатся не через зад.
С.
Guest
Передергиваешь, дружок. Я имел в виду, что если дороги хреновые, то не значит, что можно ездить на красный свет или по встречной полосе.
tony2001
TeaM PHPClub
>Коль у тебя сквозная кодировка по подкатегориям, то вот здесь и
>есть принципиальное нарушение структуры данных.
не понял в чем оно заключается.
>Если бы было, как положено в идеале (кодировка подкатегории
>ведется в каждой категории изолированно), то и не возникло бы
>проблемы.
идеальных газов, мужей и жен не существует.
>Если уж выбирать, где заморачиваться, то я выбрал бы вариант,
>который больше отвечает теоретическим принципам, даже если
>там надо кодировать чуть больше.
и где сии теоретичеcкие принципы можно почерпнуть ?
>Не известно, какие еще могут задачи встать впереди, а так есть
>шанс, что они решатся не через зад.
вот-вот.
согласен.
при твоем варианте все будет именно через это место, т.к. я буду смешивать пастбища и овец в одной таблице.
при том, иметь ограничения на количество овец на каждом пастбище.
не так, что-ли ?
>есть принципиальное нарушение структуры данных.
не понял в чем оно заключается.
>Если бы было, как положено в идеале (кодировка подкатегории
>ведется в каждой категории изолированно), то и не возникло бы
>проблемы.
идеальных газов, мужей и жен не существует.
>Если уж выбирать, где заморачиваться, то я выбрал бы вариант,
>который больше отвечает теоретическим принципам, даже если
>там надо кодировать чуть больше.
и где сии теоретичеcкие принципы можно почерпнуть ?
>Не известно, какие еще могут задачи встать впереди, а так есть
>шанс, что они решатся не через зад.
вот-вот.
согласен.
при твоем варианте все будет именно через это место, т.к. я буду смешивать пастбища и овец в одной таблице.
при том, иметь ограничения на количество овец на каждом пастбище.
не так, что-ли ?
С.
Guest
Хорошо, я согласен, что в первом варинате, я больше упор сделал на практическую реализацою, чем на ее теоретическую подоплеку. Тогда я предлагаю следующую структуру базы:
Таблица "Категории":
код, наименование,...
Таблица "Подкатегории"
код подкатегории, код категории, наименование,...
Таблица "Книги"
код книги, код категории, код подкатегории, нименование,...
Все. Где может вылезти хоть одна проблема, если четко следовать этой модели?
На практическом этапе можно говорить об объединении таблиц "Категории" и "Подкатегории", комбинировании их кодов, что я и сделал в самом начале.
С.
Guest
Опять за рыбу деньги. Где избыточность? Какое поле можно убрать, не нарушив связи?
С.
Guest
> именно такая структура у меня.
1. Да вот не такая, а с избыточными данными.
2. Так тебя только джойн смущает, а простой селект - нет? А зачем нужен джойн для подсчета количества книг в (под)категории?
3. Если у тебя будет показывать с точностью +/- 10 книг от реального их количества в категории, то ничего страшного не произойдет. А если у человека, начавшего топик, итог по заказу будет с ошибкой на два рубля выдаваться, то это вряд ли кому понравится.
Konstantin
Guest
2 C
А теория хранилищ данных, не нарушает теорию релационных баз данных?
Или это тоже не правильно применение? И пользователь должен ждать пока пару часов будет обрабатываться каждый запрос?
А теория хранилищ данных, не нарушает теорию релационных баз данных?
Или это тоже не правильно применение? И пользователь должен ждать пока пару часов будет обрабатываться каждый запрос?
tony2001
TeaM PHPClub
>> именно такая структура у меня.
>1. Да вот не такая, а с избыточными данными.
да, я это сразу сказал
>2. Так тебя только джойн смущает, а простой селект - нет? А
>зачем нужен джойн для подсчета количества книг в
>(под)категории?
как зачем?
надо мне знать кол-во книг в категории.
для этого их надо на каждой странице, где они отображаются делать джойны по двум таблицам - с родителями и детьми.
в 25-й раз повторяю - имхо это более затратно, чем хранить это значени (избыточное) в базе и делать просто селект.
>3. Если у тебя будет показывать с точностью +/- 10 книг от
>реального их количества в категории, то ничего страшного не
>произойдет. А если у человека, начавшего топик, итог по заказу
>будет с ошибкой на два рубля выдаваться, то это вряд ли кому
понравится.
речь не о нем.
З.Ы. ушел, завтра продолжим.
>1. Да вот не такая, а с избыточными данными.
да, я это сразу сказал
>2. Так тебя только джойн смущает, а простой селект - нет? А
>зачем нужен джойн для подсчета количества книг в
>(под)категории?
как зачем?
надо мне знать кол-во книг в категории.
для этого их надо на каждой странице, где они отображаются делать джойны по двум таблицам - с родителями и детьми.
в 25-й раз повторяю - имхо это более затратно, чем хранить это значени (избыточное) в базе и делать просто селект.
>3. Если у тебя будет показывать с точностью +/- 10 книг от
>реального их количества в категории, то ничего страшного не
>произойдет. А если у человека, начавшего топик, итог по заказу
>будет с ошибкой на два рубля выдаваться, то это вряд ли кому
понравится.
речь не о нем.
З.Ы. ушел, завтра продолжим.
Demiurg
Guest
Значит твоя структура бе избыточности ?
А ты не подумал, что каждая книга твоя связано с одной конкретной подкатегорией, а каждая подкатегория связана с одной конкретной категорией. А теперь вопрос. Зачем в таблице "Книги" поле "код категории" ?
И еще пример с дорогами. Как часто наши автолюбители нарушают правила дорожного движения (я не имею в виду крупные нарушения), для того, что бы быстрее доехать ? Тоже самое и для баз данных.
dr.vint
Guest
ссылка по теме
http://www.osp.ru:8083/win2000/sql/2001/05/955.htm
http://www.osp.ru:8083/win2000/sql/2001/05/955.htm
si
Administrator
вот в догонку по теме:
есть инет магазин, за пару лет накопилось уже много товара, который больше не продается, но т.к. в order_detail есть только id товара и его цена, кол-во и нет наименования, то нет возможности удалить эти товары (они сейчас помеченны как disabled).
Вот к чему привела нормализация.
Я и думаю, что можно в order_detail сделать поле product_name (как одим из вариантов).
есть инет магазин, за пару лет накопилось уже много товара, который больше не продается, но т.к. в order_detail есть только id товара и его цена, кол-во и нет наименования, то нет возможности удалить эти товары (они сейчас помеченны как disabled).
Вот к чему привела нормализация.
Я и думаю, что можно в order_detail сделать поле product_name (как одим из вариантов).
Да есть такая проблема %)
Правда изначально была избыточность (т.е. имя с товаром писалось в детали заказа)
Помогло когда пришли новые менеджеры и всесто
добавить новый поменяли товары которых нет в продаже...
А скорость можно повысить применив лимиты по записям и по времени кстати....
С.
Guest
"Утро вечера мудреннее"
или
"Телепаты вернулись из отпуска"
Наконец я понял, где собака порылась. Похоже, что ты пишешь Библиотеку Конгресса США (но вроде и там книг меньше), но дело не в этом. Тебе надо, чтобы на каждой странице выдавался список категорий и такая маленькая циферка с количеством книг в каждой, совсем как ты или твой заказчик видел на "Другом Очень Солидном Сайте".
Ради такой красивой фичи можно пойти и на извращения. Пример оправданности избыточных даных принят.
Замечу только под конец, что моя практика показывает, что чем более трудоемкий запрос для базы данных, тем реже он нужен на практике. Например отчет по всем закаказам с итогами по заказчикам за всю историю магазина имеет чисто статистический смысл и прогоняется даже не каждый день. Поэтому, если передо мной встает дилемма отступления от теории ради снижения нагрузки на систему, то я ставлю себе вопрос: "кому это надо и надо ли это вообще?".
mulder
Guest
Не народ, я вот подсмотрел такую структуру:
раз все товары одинаковые и у них различается только название, то нет смысла для каждой категории делать таблицу. А делаем так: в общей таблице товаров делаем поля: категория и родительская категория. Тогда никаких джоинов - делаешь селект по родительской категории.
tony2001
TeaM PHPClub
>Наконец я понял, где собака порылась. Похоже, что ты пишешь
>Библиотеку Конгресса США (но вроде и там книг меньше), но дело
>не в этом. Тебе надо, чтобы на каждой странице выдавался
>список категорий и такая маленькая циферка с количеством книг
>в каждой, совсем как ты или твой заказчик видел на "Другом
>Очень Солидном Сайте".
я понимаю твой сарказм, однако не стоит сводить разговор к обсуждениям деталей какого-то конкретного примера.
>Ради такой красивой фичи можно пойти и на извращения.
не стоит считать это извращением.
>Пример оправданности избыточных даных принят.
ок
теперь выводы:
весь разговор я затеял только из-за твоей категоричности.
"не при каких условиях, никогда и т.п." - это неверный подход имхо.
у каждого правила есть исключения.
структура базы в примере не идеальная (об идеальных газах я уже говорил, повторяться не буду).
смысл в чем - есть случаи, когда стОит отойти от общепринятых принципов (я называю их принципами - ты законами).
и не последнюю роль играет в этом НЕидеальность средств (языка, database engine и соотв. API).
надеюсь, что дискуссия исчерпана, все довольны, все смеются.
>Библиотеку Конгресса США (но вроде и там книг меньше), но дело
>не в этом. Тебе надо, чтобы на каждой странице выдавался
>список категорий и такая маленькая циферка с количеством книг
>в каждой, совсем как ты или твой заказчик видел на "Другом
>Очень Солидном Сайте".
я понимаю твой сарказм, однако не стоит сводить разговор к обсуждениям деталей какого-то конкретного примера.
>Ради такой красивой фичи можно пойти и на извращения.
не стоит считать это извращением.
>Пример оправданности избыточных даных принят.
ок
теперь выводы:
весь разговор я затеял только из-за твоей категоричности.
"не при каких условиях, никогда и т.п." - это неверный подход имхо.
у каждого правила есть исключения.
структура базы в примере не идеальная (об идеальных газах я уже говорил, повторяться не буду).
смысл в чем - есть случаи, когда стОит отойти от общепринятых принципов (я называю их принципами - ты законами).
и не последнюю роль играет в этом НЕидеальность средств (языка, database engine и соотв. API).
надеюсь, что дискуссия исчерпана, все довольны, все смеются.
Demiurg
Guest
Не поверишь, но именно об этом и была речь. Только зачем тебе ссылка на родительскую категорию, если категория и так на неё ссылкается ?
mulder
Guest
Где же категория ссылается на родительскую? Совсем нет. Конечно, если ты пишешь категорию как 10022411234, то да, но такой номер еще потом обработать надо...
А как например в твоем случае сделать селект по всем подкатегориям данной категории???
У меня это будет where parent_id=число,