Как лучше сделать кассовую программу-склад на PHP?

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

То есть, если программист (волею судеб, так уж получилось) в течении нескольких лет работает над крупным проектом или, например, руководит разработкой проекта, ни на что не отвлекается, становится настоящим профессионалом в своей области, но навыки работы с другими языками постепенно теряет, а сами языки меняются, то такой программист уже становится, как Вы выразились, обезьяной?

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

Перечитал сейчас еще раз эту тему. Из аргументов в пользу решения php+mysql могу выделить два основных:
1) "он и так справится", в доказательство к чему приводятся примеры проектов, в которых он "и так справляется".
2) Это дешевле. А переписывать уже написанное - это плохо, т.к. дорого.

Ни одного аргумента, чем же php+mysql лучше, быстрее, производительнее, я не увидел. Стоимость давайте оставим подсчитывать заказчикам, в конце концов, у нас рыночные условия.. Хотелось бы только, чтобы в стоимость разработки была включена еще и стоимость серверов а в ведение и поддержку проекта - еще и поддержка\апгрейд их же.

Скажите, много ли вы видели проектов, проваленных из-за того, что была использована MySQL, а не PostgreSQL, или наоборот?

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

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

А, и ещё - за время разработки я обучил своего заказчика PHP ещё глубже(по его инициативе) теперь по мелким доработкам он просто звонит и я ему ПО ТЕЛЕФОНУ объясняю что где подправить и что за что отвечает. Ну не прелесть ли

Конечно прелесть. Надо только договориться, кто будет отвечать за последствия ошибок внесенных заказчиком при выполнении таких доработок, а то ведь как бывает: поговорили по телефону, заказчик трубку повесил, стал дорабатывать, отвлекся, где-то запятую пропустил, через месяц выясняется, что у пары тысяч записей в базе какое-либо второстепенное поле заполнено нулями - пустячок, конечно, а ведь неприятно.

Перед каждым исправлением, более-менее влияющим на бд - бэкап. Вроде бы очевидно.
По последствиям - да никто. Работа на почасовке, если он что-либо напортачит - исправляю я и как бэ он оплачивает.
Хотя, когда я что-то напортачу - тоже он оплачивает

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

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

Скажите, много ли вы видели проектов, проваленных из-за того, что была использована MySQL, а не PostgreSQL, или наоборот?

Разумеется, нет=) Нет таких ошибок в проектировании и создании проекта (за исключением ну совсем уж школьных косяков), которые нельзя было бы решить добавлением лишней планки оперативки или переездом на более мощные процы...

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

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

Ну почему-же... Например, ошибки в продвижении (promotion) проекта или ошибки в организации работ по проекту - эти ошибки добавлением аппаратных ресурсов не исправляются. Так же впрочем, как не исправляются они путем использования postgres или oracle.

Другим примером может быть ситуация когда из-за ошибки проектирования, время отклика системы t зависит от количества входных запросов n квадратичным t=O(n**2) или, не дай бог, экспоненциальным образом: t=O(EXP(n)) (где O(x) означает порядок зависимости, читается "порядка x". Такие ошибки добавлением процессоров или памяти, к сожалению, не лечатся, поскольку время отклика от объема ресурсов зависит, в лучшем случае, линейным образом: t=O(n). Точно так же, эти ошибки невозможно исправить и путем выбора базы данных или языка программирования: любой язык и любая СУБД на время отклика системы, в лучшем случае, влияют линейным образом.

Практическим примером такой ситуации может быть коллапс сервера базы данных MySQL с таблицей MyISAM при достижении определенных соотношений между потоками запросов чтения, обновления и параметров этой таблицы. В этой ситуации, добавление процессоров, памяти и переход на более быстрые диски проблему лишь отодвигают, но не решают. Решается проблема или путем изменения алгоритмов или путем изменения типа таблицы, но при любом варианте, решение можно получить без замены MySQL на другую СУБД.

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

Другим примером может быть ситуация когда из-за ошибки проектирования, время отклика системы t зависит от количества входных запросов n квадратичным t=O(n**2) или, не дай бог, экспоненциальным образом: t=O(EXP(n)) (где O(x) означает порядок зависимости, читается "порядка x".

Такого рода ошибки означают что либо проект не сдан, а значит, работа над ним еще идет - либо, если выявляются в уже сданном (или по крайней мере на финальной стадии, когда надо переделывать все почти с нуля) проекте, относятся к школьным.
Интересно кстати, а как Вы определяете форму графика зависимости отклика системы от языка или СУБД когда заявляете, что она в лучшем случае линейная? У вас есть обьективная таблица сравнения СУБД и языков программирования в каких-то абсолютных величинах?

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

Интересно кстати, а как Вы определяете форму графика зависимости отклика системы от языка или СУБД когда заявляете, что она в лучшем случае линейная? У вас есть обьективная таблица сравнения СУБД и языков программирования в каких-то абсолютных величинах?

тоже интересно какая зависимость в скорости запросов в делфях, сишнике, перле и php
пруфлинк????

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

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

Другим примером может быть ситуация когда из-за ошибки проектирования, время отклика системы t зависит от количества входных запросов n квадратичным t=O(n**2) или, не дай бог, экспоненциальным образом: t=O(EXP(n)) (где O(x) означает порядок зависимости, читается "порядка x".

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

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

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

Интересно кстати, а как Вы определяете форму графика зависимости отклика системы от языка или СУБД когда заявляете, что она в лучшем случае линейная?

Это просто: производительность любой СУБД (за исключением патологически крайних случаев) ограничивается сверху пропускной способностью памяти и алгоритмами поиска на диске. Пропускная способность памяти от типа СУБД, очевидно, не зависит. Диск поддерживает только две операции: последовательное чтение и чтение по адресу сектора, скорость этих операций от типа СУБД, также, не зависит. Алгоритмы индексирования и поиска по индексу исследованы давным-давно и ничего нового там придумать уже невозможно, значит и реализация этих алгоритмов в разных СУБД будет иметь сопоставимую производительность, во всяком случае, порядок, т.е. вид зависимости пропускной способности от плотности входных запросов будет примерно одинаковым. Следовательно, в общем случае, время отклика от используемой СУБД зависит слабо. Разумеется, для каких-то запросов, СУБД "А" будет в сотни раз быстрее чем СУБД "Б", но для запросов другого вида, "Б" будет в сотни раз быстрее чем "А". В реальной жизни, большинство задач совмещают самые разные запросы, поэтому зависимость производительности СУБД от потока запросов в среднем по всем запросам будет примерно одинакова для всех СУБД. К тому же, все СУБД оптимизируют под некий среднестатистический набор запросов. Разумеется, если мы знаем, что проектируемая система, в основном, занимается выборкой из БД, а пишет в нее изредко и только по выходным, мы должны ориентироваться на СУБД оптимизированную на выборки данных. В реальной жизни, такие системы попадаются, но не очень часто.

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

У вас есть обьективная таблица сравнения СУБД и языков программирования в каких-то абсолютных величинах?

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

Говоря о тестах - если есть желание выбрать самую лучшую СУБД для данной конкретной архитектуры, то в комплект MySQL входит набор тестов sql-bench которым (как они говорят) можно измерять разные СУБД (включая postgres). Нагрузочные испытания MySQL можно делать тестом SuperSmack - они говорят, что он может "убить" любую базу (правда, у меня это так и не получилось).

Очень эмоционально об особенностях сравнительного тестирования MySQL и postgres было написано в руководстве по MySQL 4.x, правда в 5-й версии этот раздел убрали (видимо, по соображениям политкорректности )

Непосредственно к началу темы.

Можно и на пхп сделать. Я бы делал на ZenD framework (php фреймвок) - потому что там нужно постараться чтобы написать ломаемый код. А на голом пхп надо постараться чтобы такой не написать. Хотя, это ИМХО.

Не знаю почему тут высказано что это делать крайне сложно. ТЗ за 1000 . Ерунда. Здесь видно пугают слова "терминал" и т.п. Т.е. неясность задачи. Как я вижу, речь идет о модифицированном инет-магазине. Не больше не меньше. И делается такой проект порядка 1 мес. Цена ему - 800-2000 у.е. (смотря кто делает, у каждого свои тарифы)

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

Непосредственно к началу темы.

Именно!

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

Можно и на пхп сделать....

Лучше всего - не делать вообще. Взять что-либо готовое и доработать. Поскольку требуется не более и не менее чем обычный интернет-магазин, то это будет оптимальное решение. Самая лучшая программа - это та, которую не надо писать.

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

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

Непосредственно к началу темы.

Именно!

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

Можно и на пхп сделать....

Лучше всего - не делать вообще. Взять что-либо готовое и доработать. Поскольку требуется не более и не менее чем обычный интернет-магазин, то это будет оптимальное решение. Самая лучшая программа - это та, которую не надо писать.

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

п.с. У меня есть пару движков (своих), и иногда не хватает времени на заказы. Интересно, за сколько б вы согласились изменить мой движок под мои требования? Рыться в чужом коде крайне неприятная задача. Я думаю об этом и спорить не нужно. Т.к. про это сказано очень многое

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

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

А про оптимизацию запросов автор слышал?

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

)) очень часто в чужом коде крайне сложно разбираться.

К сожалению - да. Очень часто, программисты забывают (или не знают), что код пишется не для машин, а для людей. Бывают, конечно, исключения, но не очень часто.

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

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

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

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

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

Это деловое предложение?

Illarion_SA, для того, чтобы определить форму графика, необходимо каким-то образом расположить СУБД и языки программирования на одной оси. Тоесть количественно сравнить их по какому-либо показателю. Например, если бы они все были платными - таким показателем могла бы стать стоимость. Так как, Вы абсолютно правильно сказали, что обьективно сравнить их не представляется возможным, любые заявления относительно "в лучшем случае линейной" зависимости времени отклика от выбранной СУБД или языка программирования - абсурдны.

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

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

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

А про оптимизацию запросов автор слышал?

Немножко слышал, совсем чуть-чуть. Если алгоритм поиска записи в файле, например, ISAM обеспечивает теоретически-достижимый порядок O(n*LOG(n)) (не ручаюсь за точность формулы), то оптимизатор запросов сможет лишь увеличить количество запросов скорость обработки которых приблизится к этому пределу. В общем случае, оптимизация запросов степень алгоритма обработки не изменит, поскольку сама эта степень была получена в предположении, что все запросы уже предельно оптимальны, все работает бесконечно быстро и ни на что не отвлекается. Конечно, в частных случаях возможны исключения, например в таблицах MyISAM (снова про MySQL), функция count(*) работает поразительно быстро (это связано со структурой MyISAM), но вот часто-ли в реальной жизни приходится делать "SELECT count(*) FROM ..."?