но при этом все одно не атомарно

Ну да.. так все и есть

А если Сервер БД подменять типо обновлии данные на одном, потом переключились на другой.

всякие заказы и тп могут просратся в момент переключения

Даже не так

к тому же там жумла)

с какимто опенкартом

Переключаем не Сервере. А тоолько имя базы подменяем

или чемто таким

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

вот в случае постгреса прокатит, я даже как-то костылил в свое время систему версионирования данных на основе схем ;)

или чемто таким

Чем вам не угодил опенкарт...

))

Чем вам не угодил опенкарт...

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

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

Да, развлечение так себе. Я думаю ни одного магаза на ОК не возникнет ткой задачи. 2. Я думаю если возникнет, то меня это не остановить. Тк.. выбор будет такое - либо не обновлять данные быстро и терять выгоду с продаж. Либо помучатся и в будущем заработать бабки. Мне выбор очевиден.

Да, развлечение так себе. Я думаю ни одного магаза на ОК не возникнет ткой задачи. 2. Я думаю если возникнет, то меня это не остановить. Тк.. выбор будет такое - либо не обновлять данные быстро и терять выгоду с продаж. Либо помучатся и в будущем заработать бабки. Мне выбор очевиден.

+1

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

сначала надо вгрузить 25млн товаров )

это не ИМ

не классический ИМ на 1000 товаров на складе

это типа агрегатора с функцией оформления заявки на заказ

не классический ИМ на 1000 товаров на складе

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

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

Да сейчас мало того что сам сайт работает, ещё 100 агрегаторов интегрируются сверху + 100 выгрузок хрен знает куда + 100 пикселей для статистики + 100 гуглояндексоВкОдноклассникотрекеров

И потом крики "БЛ*!!! САЙТ НИРАБОТАЕТ ВООБЩЕ!!!расрасрас за что мы платим бабки?! всё плоха вы ниработаете"

Жизнь - боль))

Один пессимизм. Положительная строна. Ваши клиенты могут все купить в одном месте. И это благодяря битриксу и ПХП!!!!

Без ПХП ничего не было бы

Без ПХП ничего не было бы

Без JAVA не было бы PHP)

Без JAVA не было бы PHP)

Без С++ не было бы JAVA

Без С++ не было бы JAVA

Без Assembler не было бы C++ и этого чата)))

джява вышла попозже пшп

джява вышла попозже пшп

Ну на год, и то в 1994 году пшп был совсем не тот, который сейчас на 50+% копия джавы

Ну то есть джава это просто т ренировочная площадка для пшп

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

Ахаха) Ну столько гавнокода, сколько есть на PHP, боюсь подумать сколько его на яве

Сам прогал на Андроид на Яве по детству програмки, которые дергают апи сайтов

Прочитал тут на днях, что оборачивать приложение в try catch это плохая идея. Можете объяснить почему?

Оборачивать приложение?

Именно не отдельные куски кода, а все приложение. Типа верхний try catch которые ловит все. В моем пониамние это удобно т.к. можно ловить все и логировать

Вопрос очень контекстуальный и ситуативный

Оборачивать приложение?

Да. По типу в infex.php где иницализируется приложение обернуть его в try catch не есть хорошо. Хочу понять почему

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

25 млн позиций - это не то чтоб очень много

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

переименование таблиц требуется никогда совсем :)

Господа, добрый вечер. Ситуация: две таблицы "статьи" и "комментарии". В таблице статей есть поле is_enabled которое отвечает за состояние включен/выключен Каждый комментарий к статьям связан с полем article_id в таблице статей Каким образом на Ваш взгляд самый оптимальный способ получить ТОЛЬКО те комментарии, чьи статьи имеют is_enabled = 1?

точно неискусан? ни разу? никогда?

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

какой критерий оптимальности?

какой критерий оптимальности?

резонный вопрос

вы чертовски правы

я сломлен, потому что не знаю, что на него ответить :с

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

Делай как я тебе говорил потому-что :3 В моем запросе учтены все возможные будущие и прошлые кейсы.

Делай как я тебе говорил потому-что :3 В моем запросе учтены все возможные будущие и прошлые кейсы.

https://stackoverflow.com/questions/25059779/mysql-select-having-count

это?

Ну да, там ведь можно и джоин подсунуть и любые условия.

Сначала напиши чтобы работало а потом если будет тормозить то уже занимайся вопросами оптимизации. Там решения могут быть очень разные

Вплоть до предвычисления всех возможных выборок и засовывания их в кеш

А чем обычный джоин не устраивает?

Да вот не рекомендуют его

не сказал бы что having лучше, но есть подозрение, что в плане запроса будет обычный подсчет кол-ва на каждую запись, ничего хитрого, поэтому сомневаюсь в его лучше скорости, по сравнению с джоином

Сначала напиши чтобы работало а потом если будет тормозить то уже занимайся вопросами оптимизации. Там решения могут быть очень разные

принцип строительства кемеровского ТЦ

За такой неуместный комментарий вам бы бан выписать, Григорий ?

За такой неуместный комментарий вам бы бан выписать, Григорий ?

скорее это упрёк в адрес системы

почему? чем же он неуместный? там делали именно так - лишь бы работало

что понять можно, поскольку всё действительно не хорошо

ERROR: S client not available

денег щас прямо быстро и без забот

почему? чем же он неуместный? там делали именно так - лишь бы работало

В моем утверждении нет ни намека на "делать лишь бы работало" :) Все неправильно понято.

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

кем понято? автор вопроса ничего не понимает

Какие там проблемы? Нафантазировали себе

неработающая система обычно считается проблемой

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

В чем я сомневаюсь в принципе

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

именно так

Да это какие-то бредовые аналогии, я не понимаю о чем они

Переход на личности тебя характеризует не самым лучшим образом

этот подход называется "хренак-хренак, и в продакшн"

Так не надо ваши подходы другим приписывать

?

согласен, перегнул с ярлыками, прости

держите пчёлку

чтобы не ссорились

я хочу сказать не о тебе, а о том, что этот конкретный совет - вредный

лишь бы заработало, а там как будет - это неправильный путь, он ведет к бедности и увольнениям

я хочу сказать не о тебе, а о том, что этот конкретный совет - вредный

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

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

"Сначала напиши чтобы работало а потом если будет тормозить то уже занимайся вопросами оптимизации" - как это понимать?

как определить уже тормозит, или еще нет?

Так и понимать. Если в табличке 10 статей и 1000 комментариев то джоин там прекрасно работает

когда становится пора оптимизировать?

а если 10 тысяч статей и 500 тысяч комментариев?

когда становится пора оптимизировать?

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

у кого будут на то причины? я отвечу: у начальника

это называется безответственность

или на него будут орать, как на Джумшута, или уволят

у кого будут на то причины? я отвечу: у начальника

Кто такой начальник? По какому критерию его определить?