Паттерны программирования и PHP

Цитата ("raznomir"):

Как бы вы решили эту задачу с точки зрения хранения данных?

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

Цитата ("Lisio"):

Если нет - еще одна таблица с тремя полями (регион, метод, цена), причем регион и метод через триггеры. Если регионов много, то на это поле индекс навесить.

Вот!
Чего и следовало доказать.
Берется прямое решение, типичное для настольных программ, и даже не допускается мысль о существовании иных способов.
Еще подсказка: подумайте, сколько максимум может быть методов доставки?

Дорогие ребята "ООП-медленно, ресурсоемко" - вы с отладчиком хоть раз сидели?
Вы вообще представляете как это все хранится в памяти?) Сколько байт отличает переменную глобальную от переменную в классе?
Узкое горлышко, мне кажется, не здесь

Цитата ("raznomir"):

и даже не допускается мысль о существовании иных способов

Почему же, допускается. Только не применяется. И тем более не зная точной конкретики задачи.

Цитата ("raznomir"):

Еще подсказка: подумайте, сколько максимум может быть методов доставки?

Опять же, именно конкретика задачи меняет ее суть. Постом выше не накладывается ограничение на число методов доставки. Если методов мало, то их самих можно сделать полями таблицы, выставляя цену на пересечении.

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

Цитата ("Lisio"):

Почему же, допускается. Только не применяется. И тем более не зная точной конкретики задачи.
Опять же, именно конкретика задачи меняет ее суть. Постом выше не накладывается ограничение на число методов доставки. Если методов мало, то их самих можно сделать полями таблицы, выставляя цену на пересечении.
Ставьте задачу конкретнее и получите более оптимальное решение для нее, т.к. вытягивать из вас все входные данные не имеет смысла на форуме.

Скажите это заказчику, насчет ставить задачу конкретнее. Чем более конкретно поставлена задача, тем меньше надо думать программисту - так можно дойти и до уровня оператора ПК, которому тупо диктуешь код, а он его набирает... Этим и отличается профессиональный программист от простого кодера, что он сам сообразит, может или не может быть в реальном мире (по крайней мере на сегодняшний день) методов доставки более чем 100-200, так чтобы в принципе в таблицу влезло в виде полей (ну а если сомневается, то как минимум у заказчика сам уточнит, а не будет от него ждать конкретизации). Сам подумает о том, что вытягивать потом цену гораздо быстрее и удобнее без третьей служебной таблицы, а напрямую и дополнительных колонок, особенно если колонки назвать по формуле с кодом метода, так что само название колонки потом станет переменной, ну и так далее. А все входные данные я дал изначально...

Впрочем, это был именно пример, чтобы показать, что привычка НЕ думать, а делать по стандартному варианту, как раз и приводит потом к появлению различного рода монстров. ООП вещь хорошая, но, повторюсь, для веба - именно на этапе проектирования. А в реализации - убирать надо все эти промежуточные связи, многоуровневые построения, и тому подобное. Все технологии должны быть использованы уместным образом. А то были у меня знакомые ребята... что допроектировались с использованием ООП до того, что у них была отдельная гигантская таблица абсолютно ВСЕХ объектов системы, в которой было только два поля - идентификатор и название...

raznomir, вы видимо не тем занимаетесь. Попутали задачи project-менеджера и программера. Программист должен думать как реализовать ту или иную задачу, выбирать оптимальный способ, либо тот, что удобнее. Но задачи ставятся заказчиком, условия узнаются у него же. Конкретика также уточняется у заказчика. ДО реализации, а не делается так, как этого хочет программист. Вот к примеру, недавно поднималась тема про использование TIMESTAMP. Я никогда не использую этот тип данных, но если заказчик захочет - буду использовать для его удобства, объяснив побочные эффекты такого решения. Именно поэтому заказчик уточняет детали, а заниматься творчеством - дело дизайнеров. Если же вы берете проект и делаете его таким, каким видите вы, а не заказчик, то это чревато при сдаче проекта вердиктом "Вообще-то тут заказчик я, а не вы". Конечно, бывают заказы "Хочу сайт про туризм. Функционал, дизайн и вся задумака - ваша проблема, я только плачу деньги", но их не так много.

Почему я не уточнил у вас: а оно мне надо? Забесплатно я не буду вытаскивать из вас ТЗ. Тут форум, а не сборник задачек. Поэтому указал два абсолютно типовых и универсальных вариантов решения, не приводящих к какому-либо ощущаемому расточению ресурсов.

Цитата ("Lisio"):

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

Программирование без творчества - это кодинг, не путайте понятия. Да, кодеру дается очень четкая задача вплоть до типов входных и выходных данных, да еще и кучу требований к самой реализации задачи. А программирование, особенно веб-программирование, и совсем особенно веб-программирование сайтов под ключ, это в первую очередь проектирование сайта в целом. В таких проектах заказчикам глубоко фиолетово, какой именно тип данных будет использоваться с технической точки зрения, но совсем не фиолетово скорость загрузки страниц сайта. И именно веб-программист, как специалист в разработке сайтов, должен ставить и решать технические задачи, так чтобы они лучшим образом решали бизнес-задачи заказчика. А бизнес-задачи заказчиками ставятся даже не настолько подробно, как я описал задачу про методы и регионы доставки - нет, это УЖЕ проанализированная и оптимизированная задача! Заказчики в подобных случаях пишут вообще на уровне "пользователь оформляет заказ, выбирает способ доставки" и далее подробненько, но совершенно несистематизировано, перечисляют, какие у них бывают виды доставок, а в конце еще "ну и может, потом еще какой-то вид доставки появится"...

Цитата ("Lisio"):

Почему я не уточнил у вас: а оно мне надо? Забесплатно я не буду вытаскивать из вас ТЗ. Тут форум, а не сборник задачек. Поэтому указал два абсолютно типовых и универсальных вариантов решения, не приводящих к какому-либо ощущаемому расточению ресурсов.

Забесплатно Вас никто не заставлял вообще отвечать. Но если уж взялись за дело, то делайте его на 100%. Тем более, что я ясно дал понять, что задача была дана именно для того, чтобы показать, как НЕ надо использовать стандартные варианты - и Вы мне тут же предлагаете типовой вариант решения?

Цитата ("Lisio"):

Попутали задачи project-менеджера и программера.

Это Вы чего-то путаете явно. Проект-менеджер не есть проектировщик систем. Его задача в этой части - это максимально полно вытащить информацию из заказчика, чего тот хочет. Но никак не заставить заказчика спроектировать систему вместо веб-программиста (ох, некоторые заказчики такого напроектируют...).
Ну хотите, выделяйте отдельно еще и веб-проектировщика... Вот только даже проект-менеджеров для сайта, а в ряде случаев и отдельных дизайнеров, и то не увидишь... Все в одном человеке... даже переводы на английский...

Цитата ("raznomir"):

А программирование, особенно веб-программирование, и совсем особенно веб-программирование сайтов под ключ, это в первую очередь проектирование сайта в целом.

Веб-программирование сайтов под ключ? Это как? Создание сайта под ключ я знаю, а веб-программирование - это как? Кодер, который занимается и дизайном и версткой и project-менеджментом?

Цитата ("raznomir"):

задача была дана именно для того, чтобы показать, как НЕ надо использовать стандартные варианты - и Вы мне тут же предлагаете типовой вариант решения?

Ну уж потратьте время, почему такой типовой вариант "НЕ надо использовать"? База рухнет? Сервак сдохнет от натуги?

Цитата ("raznomir"):

Но если уж взялись за дело, то делайте его на 100%.

Вот если решили поумничать, написав задачу, то и выдавайте 100% вводных. Иначе это не задача, а вопрос "В чем смысл жизни?".

Цитата ("raznomir"):

Его задача в этой части - это максимально полно вытащить информацию из заказчика, чего тот хочет.

А я про что? Явно не задача программиста.

Цитата ("raznomir"):

даже переводы на английский...

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

Когда человек задает задачу, выслушивает ответ и потом говорит, что есть еще вводные данные и выдает свой "правильный" вариант - то это понты. Тупо понты.

В-общем я понял. Да, конечно, кодерам задачи оптимизации и проектирования ни к чему. Извините, что потревожил.

Видимо не поняли. Задачи - нужны. Задачи! Но не торопитесь называть огрызок информации задачей. Огрызки в мусор летят. Я думаю, это даже ежу должно быть понятно.

Raznomir, я на твоем месте еще больше бы втоптал товарища в грязь, не только отказавшись от начальных условий "Есть два объекта (Методы доставки и Регионы доставки), которые могут создаваться/удаляться в процессе работы сайта как угодно" и сказав "ХА-ХА а способов-то доставки на самом деле парочка-троичка", но и *барабанная дробь* компания работает только с одним регионом!
вот это бы унизил его как программиста, так унизил...
фууууу, как непрофессионально(

Цитата ("raznomir"):

Есть два объекта (Методы доставки и Регионы доставки), которые могут создаваться/удаляться в процессе работы сайта как угодно, сами экземпляры объектов храняться в обычных таблицах в БД, тут все просто, стандартно и очевидно.
И есть значение Стоимость, которое существует на связи этих двух объектов, то есть для каждого региона и метода доставки будет своя одна конкретная стоимость.
Как бы вы решили эту задачу с точки зрения хранения данных?

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

Ну вот смотрите, Методы доставки и Регионы доставки часто ли меняются в системе? Часто ли изменяются цены, и, главное, кем изменяются? Насколько много регионов (сколько их в РФ... вроде 89, и в Украине где-то 24, и т.д.)?
В подавляющем большинстве случаев для такой задачи не нужна база данных вообще, а эту информацию можно хранить, скажем, в XML, который после обновления вручную единственным админом-владельцем магазина сразу валидируется, парсится и подгружается в кеш.

И наоборот, если с системой работают одновременно много разных людей-операторов, в том числе и весьма далеких от IT, важно журналирование всего что происходит, принципиально необходимо сохранение целостности данных в режиме реального времени, повышенные требования к надежности и отказоустойчивости при условии конкурентного доступа и т.д., то однозначно верно лишь решение с третьей таблицей, по типу того, что Lisio предложил.

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

Цитата ("raznomir"):

тим и отличается профессиональный программист от простого кодера, что он сам сообразит, может или не может быть в реальном мире (по крайней мере на сегодняшний день) методов доставки более чем 100-200, так чтобы в принципе в таблицу влезло в виде полей (ну а если сомневается, то как минимум у заказчика сам уточнит, а не будет от него ждать конкретизации). Сам подумает о том, что вытягивать потом цену гораздо быстрее и удобнее без третьей служебной таблицы, а напрямую и дополнительных колонок, особенно если колонки назвать по формуле с кодом метода, так что само название колонки потом станет переменной, ну и так далее.

Да ну что Вы такое говорите, с отдельным полем для каждого типа доставки...

Типичнейшая ситуация, где-то 90% встреченных мной вебшопов в рунете. "Выберите метод доставки":

1. Почта России
2. Доставка курьером (только Москва)

И что, делать два поля в таблице, то есть для каждого из этих типов доставки, хотя лишь только один из регионов (Москва) покрывается доставкой курьером, и остальные будут всегда пустыми?
Далее, завтра заказчик захочет вдруг еще добавить "Экспресс доставка DHL", и что, менять схему данных и добавлять новую колонку?
В общем, неудачный пример IMHO, да еще и не в тему.

Цитата ("tvv"):

В подавляющем большинстве случаев для такой задачи не нужна база данных вообще, а эту информацию можно хранить, скажем, в XML, который после обновления вручную единственным админом-владельцем магазина сразу валидируется, парсится и подгружается в кеш.

Да, это еще один замечательный вариант решения. А в ряде случаев даже XML не нужен, а достаточно отдельного php-файла, в котором напрямую присвоены нужные значения в массивах. Причем, этот файл же преспокойно можно менять (перезаписывать) в процессе работы сайта (т.е. если админ поменяет что-то в методах/регионах), чего не позволяется в настольных системах! Потом обычный include - и все, у нас уже вся инфа о доставке есть.

Цитата ("tvv"):

И наоборот, если с системой работают одновременно много разных людей-операторов, в том числе и весьма далеких от IT, важно журналирование всего что происходит, принципиально необходимо сохранение целостности данных в режиме реального времени, повышенные требования к надежности и отказоустойчивости при условии конкурентного доступа и т.д., то однозначно верно лишь решение с третьей таблицей, по типу того, что Lisio предложил.

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

Цитата ("tvv"):

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

А я не просил дать однозначный вариант. Я хотел показать пример как раз НЕоднозначного решения задачи.

Цитата ("tvv"):

И что, делать два поля в таблице, то есть для каждого из этих типов доставки, хотя лишь только один из регионов (Москва) покрывается доставкой курьером, и остальные будут всегда пустыми?

А вам жалко оставить два поля пустыми? Значит, скорость загрузки нам не важна, а место на сервере резко стало сверхценностью?

Цитата ("tvv"):

Далее, завтра заказчик захочет вдруг еще добавить "Экспресс доставка DHL", и что, менять схему данных и добавлять новую колонку?

ИМЕННО!!!! Добавлять новую колонку, обычным sql-запросом, из обычного php-скрипта вызывая оный. Что этому мешает-то? То ли невозможность менять структуру БД в настольных программах, то ли что? Говорю же, в вебе намного меньше ограничений - но вот почему-то большинство разработчиков так и ходит на короткой цепи, не выходя за круг обозначенный, хотя самой цепи уже и в помине нет.

Цитата ("tvv"):

В общем, неудачный пример IMHO, да еще и не в тему.

А я наоборот, убедился, что пример как раз великолепный получился. Именно чтобы выявить стереотипы мышления. Что и произошло. Не корысти ради, а токмо по велению души, что не терпит дилетантства в любом деле, и программирование не исключение.
Что не совсем в тему про паттеры - согласен, но именно что чуток не совсем. Паттерны - это тоже своего рода приучивание себя НЕ мыслить, а действовать по привычке. Что в большинстве случаев вполне уместно и хорошо (не думать же каждый раз, когда ногу передвигаем, так и проблемой сороконожки можно обзавестись), но хоть иногда же надо осознавать, а чего и как, собственно, я делаю?

Цитата ("raznomir"):

А я наоборот, убедился, что пример как раз великолепный получился.

Пример чего? Вашего непонимания разницы между постановкой задачи для решения и неполноценного ТЗ? Согласен, пример замечательный. У меня даже лучше есть: "Есть данные. В чем будете хранить"?

Цитата ("raznomir"):

ИМЕННО!!!! Добавлять новую колонку, обычным sql-запросом, из обычного php-скрипта вызывая оный. Что этому мешает-то? То ли невозможность менять структуру БД в настольных программах, то ли что? Говорю же, в вебе намного меньше ограничений - но вот почему-то большинство разработчиков так и ходит на короткой цепи, не выходя за круг обозначенный, хотя самой цепи уже и в помине нет.

Вы действительно предлагаете такое решение Вашим клиентам в реальных проектах? Ответьте пожалуйста честно.

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

Цитата ("raznomir"):

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

У меня есть не только предубеждение, а вообще уверенность, что такое решение — категорически неприемлемо.
Вы, конечно, сделали оговорку "когда это уместно", таким образом защитившись... но все же я попробую привести аргументы.

1. Надежность. Надеюсь, Вы знаете что такое журнализация изменений, и в чем разница между DDL и DML операциями в этом оотношении. Если в результате DDL операции происходит сбой по любой причине, то в большинстве СУБД (я не имею в виду MS SQL) транзакционный движок не сможет сделать откат назад. Придется восстанавливать из бакапа, что чревато частичной потерей данных на живом проекте, чревато потерей времени, чревато остановкой проекта в течении этого времени, и т.д. А вот в отличие от этого, при DML операции все пройдет гладко и незаметно.

2. Избыточность. Дело не только в том, что мне "жалко" оставить несколько полей пустыми, дело в самом подходе. Городить избыточные конструкции без особой на то необходимости... Я написал выше пример с доставкой курьером только для Москвы, чтобы показать, что при таком подходе будет весьма много пустых полей. Это не только занимает лишнее место на диске, но и затрудняет дальнейшую обработку в коде. И таки да, на скорость это также отрицательно скажется, и на таких небольших объемах данных не даст никакого выигрыша в производительности по сравнению с третьей таблицей (все равно все целиком сидит в кеше).

3. Целостность. Надеюсь, Вы знаете что это, и зачем это нужно. Каким образом Вы можете обеспечить в Вашем проекте целостность данных, когда какие-то ключи (в данном случае — методы доставки) захардкожены в виде полей? Например, добавили новый вид доставки. А колонку не добавили. Это — нарушение целостности, которое в Вашем случае никак средствами базы данных не проверяется (или специально триггер или хранимую процедуру для этого пишите?).

4. Нормализация. Надеюсь, Вы знаете что это, и зачем это нужно. Ваш же метод — наоборот, это типичный пример денормализации, которого следует избегать без наличия веских причин (например, если это критично в плане производительности, что в Вашем случае не так). Чем это чревато, можете ли сами догадаться?

5. Расширяемость. Например, пришло новое требование от заказчика. Теперь от Региона и Метода доставки зависит не только цена, но еще и время доставки. Весьма типичная задача. И что, в Вашем случае нужно будет добавить еще кучу столбцов типа "почта_время", "курьер_время" и т.д. в таблицу регионов?

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

Кстати, вдогонку.
Если уж Вам нравится такой формат вывода как "Регион - цена_почта - цена_курьер", то что Вам мешает написать для этого вьюв? Выводиться будет как раз в том формате, как Вы захотели... Но сами данные лучше уж не трогать, пусть они в базе данных размещаются правильно, в нормализованном виде...

Понимаете, веб, отсутствие рамок, и прочее — это всё конечно хорошо, но фундаментальными принципами построения хранилищ данных (в данном случае реляционных) пожалуйста не пренебрегайте.
Иначе Ваш удел будет лишь втирать кривые решения неквалифицированным заказчикам, которые не могут отличить профессиональную работу от ремесленной любительской поделки.