Список заказанного товара есть где ?

[SP 0]

Хочется иметь список (в идеале печатать) товара, который заказан, но не отгружен,

т.е. всего того, что магазин должен клиентам.

Есть какой-нибудь готовый модуль или отчет ?

[support 447]

Разве что в Админке - Покупатели - Заказы можно отфильтровать заказы по статусы, т.е. например на статус неотгруженные.

Ну а что б вот так прям списком товары, такого нет отчёта.

[SP 0]

Заказы != Товары.

Склад наверное умилится получив список "зарезервируйте что-то для петрова, нечто для иванова итп".

Самому значит доводить зубилом...

[support 447]

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

Можно чуть доработать список заказов, что б товар сразу в список выводились без выделения, либо ещё как.

[SP 0]

Извратил "заказанные товары". Часа полтора вместе с разборкой с БД.

БД конечно в некоторых местах "очень не айс" :( 

Что там должно было быть на самом деле осталось загадкой.

Попадало туда что-то странное.

[support 447]

В смысле, не айс, что конкретно, можно пример?

[SP 0]

В прямом. "Не айс = ахтунг".

К чему в таблице товаров вся эта эээ... боюсь сказать "хня" ?

Есть таблица с историей статуса заказа, есть статус заказа в заказах.

Зачем ?  Нафига хранить информацию в двух местах ?

В orders - customers_status_name нафига ? 

customers_status_image нафига ? ЗАчем ДВА текстовых поля заполненных словами

типа "покупатель - покупатель.гиф в 90% случаев" ?

Зачем в order инфорация о ФИО покупателя вообще :) ?

Они что меняют имена :) ?

shipping_method - тоже заполнено через одно место...

И так повсеместно.

Никакой нормализации.

Возможно, что-то неуловимо поменялось в программировании, но я всегда считал

что данные не должны храниться более, чем в одном месте.

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

Проблема только в том, что дописывать что-то в такую базу практически нереально.

(невозможно найти ВСЕ места где кому-то взбрело в мозг что-то откопировать)

[ABerezin 0]

Слишком эмоционально для анализа проекта.

Возможно, что-то неуловимо поменялось в программировании, но я всегда считал

что данные не должны храниться более, чем в одном месте.

Нет, ничего не поменялось - не должно всё храниться только в одном месте. Избыточность нужна.

Есть таблица с историей статуса заказа, есть статус заказа в заказах.

Зачем ?  Нафига хранить информацию в двух местах ?

Очень просто - чтобы не лезть каждый раз в таблицу истории заказов, откуда выбирать по ид заказа последнюю запись, чтобы выяснить текущий статус заказа.

В orders - customers_status_name нафига ?  

customers_status_image нафига ? ЗАчем ДВА текстовых поля заполненных словами

типа "покупатель - покупатель.гиф в 90% случаев" ?

Зачем в order инфорация о ФИО покупателя вообще :) ?

Они что меняют имена :) ?

Да, меняют. А что, это откровение для Вас? И имена меняются, и адреса и другие данные. И аккаунты удаляются. И с товарами аналогично - товары удаляются, наименования товаров меняется, цены меняются. А заказы уже не могут измениться - это статическая информация.

Если Вы не используете поле customers_status_image - это не значит, что оно лишнее - есть пользователи, которые используют его активно.

Никакой нормализации.

Ну уж прямо так - "никакой"! Следуя Вашей логики нормализации нужно объединить таблицы products, products_description, products_to_categories. Кстати, в некоторых примитивных скриптах так и сделано.

Проблема только в том, что дописывать что-то в такую базу практически нереально.

(невозможно найти ВСЕ места где кому-то взбрело в мозг что-то откопировать)

Почему? Достаточно перед "дописыванием" в базу разобраться со структурой этой базы. И тогда всё становится весьма просто.

Структура не идеальна. Разумееется она требует оптимизации (не тупо нормализации, а оптимизации, т.е. разумного сочетания нормализации и избыточности). Это постоянная работа в любом живом и более-менее серьёзном проекте. И проводиться она, думаю Вам известно, должна не на основе визуального анализа схемы БД, а на основе анализа запросов к БД.

[SP 0]

>Слишком эмоционально для анализа проекта.

За деньги я готов провести консалтинг, бесплатно поделиться ощущениями, логично ?

>Нет, ничего не поменялось - не должно всё храниться только в одном месте. Избыточность нужна.

Я стар... уже не переподготовиться.

>Да, меняют. А что, это откровение для Вас? И имена меняются, и адреса и другие данные. И аккаунты удаляются.

>И с товарами аналогично - товары удаляются, наименования товаров меняется, цены меняются.

>А заказы уже не могут измениться - это статическая информация.

Я писал про адреса и товары ?  Я писал про ФИО.  У клиентов правда меняются ФИО :) ?

Бывало ?  В процессе получения заказа прям ?  И что, они хотели, чтобы у вас оно осталось старое ?

А как они потом получали заказ на старое фио ?

Удаляются аккаунты ?  Нет проблем - помечайте их как удаленные...

Меняются фио - хотите следить за этим - нет проблем, заведите таблицу истории фио :)

Статистика изменения ФИО :) ?

>Если Вы не используете поле customers_status_image - это не значит, что оно лишнее - есть пользователи, которые используют его активно.

Текстовое поле заполненное именем гифа ?

Вы всерьез :) ?  ID гифа и таблица соответствия id->name - это простите пример для первокурсников.

ID способа доставки даже есть, нафига имя по-русски ?

>Ну уж прямо так - "никакой"! Следуя Вашей логики нормализации нужно объединить таблицы products, products_description, products_to_categories.

>Кстати, в некоторых примитивных скриптах так и сделано.

Кстати, зачем они разделены :) ?  products и products_description Это показатель хорошего дизайна ?

products_to_categories причем тут ?  она отношение один-много задает вроде бы ?  Как их можно объединить ?

Примитивный скрипт - самый лучший скрипт. Только зеленые юнцы думают что крутизна в наворотах.

Крутизна в функционале без наворотов.

>Почему? Достаточно перед "дописыванием" в базу разобраться со структурой этой базы. И тогда всё становится весьма просто.

Эмоциональный ответ "по кочану".

Технический: видите ли, у меня нет желания разбираться со структурой базы.

У меня есть желание найти нужные данные и модифицировать их. И в проекте созданном

нормальными людьми это просто, найдя данные я знаю что они ТОЛЬКО тут.

В столь пропагандируемом вами подходе я НИКОГДА не узнаю все ли места я нашел.

Мест либо одно, либо много... увы. Если их много... аудит вы не прошли... следующий.

Собственно мне не платят за улучшения VAM Shop. Для столетней давности проекта,

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

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

неплохо, для крупных он неприменим. Я высказал мнение, меня переспросили, я

аргументировал. Разговоры о профпригодности в другое место... мне никому свою

доказывать не интересно, мне и так некисло платят.

ЗЫ. Как я уже писал, все вместе заняло часа 1-3, уж не помню сколько.  С чаем итп.

Но был неприятно удивлен открывшимся видом...

[SP 0]

>Очень просто - чтобы не лезть каждый раз в таблицу истории заказов,

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

Извиняюсь - пропустил.

Вот за такое лет 10 назад меня "долго прессовали оба технических директора".

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

Это пример УЖАСАЮЩЕГО дизайна. Сейчас меня за такое уволили бы "нах" сразу...

Ибо подобный ход - явный саботаж проплаченный конкурентами...

Хотите часто знать - имейте библиотечную функцию.

Боитесь за производительность. Не бойтесь выборки быстры.

Очень боитесь - кешируйте. Но хранить в БД рассчетные значения - сразу

"в угол". Исключения бывают, но они касаются скорее производительности

в тех случаях, когда иначе никак...

[ABerezin 0]

> За деньги я готов провести консалтинг, бесплатно поделиться ощущениями, логично ?

- для Вашего возраста логично, для меня уже нет.

> Я стар... уже не переподготовиться.

Не кокетничай :)

Не хочу спорить - не интересно. Слишком уж собственое видение возведено в абсолют. Считай что прав.