Еще пара нюансов
Номенклатура 30000+
Цена на позицию из разных партий в разных точках — разная.
И обновляется довольно часто.
XML выгрузка получается ну просто совсем неприличных размеров.
На коже — ожог и т.к. он хорошо растворяется в липидах — то все равно проникает.
Ну и в рот его занести не такая большая сложность.
И испарениями надышаться — нефиг делать.
Можно чуток поумничать?
Абразивная поверхность на спичечном коробке — красный фосфор с абразивной пылью (например стекло) итд.
При возгонке — получается белый фосфор, который быстро окисляется, отсюда и дымок и свечение.
Летальная доза белого фосфора для взрослого мужчины составляет 0,05—0,1 г.
Есть такие затейники.
Недавно попался очередной перл подобных ЦМСостроителей.
Простой отчетик по заказам на сайте, вначале месяца формируется еще терпимо, к концу месяца начинает тупить минут по 10 (если не обламывается по лимиту памяти). На выдаче у него от силы 3К строчек, типа №/Датавремя/Покупатель/Точка продажи/Сумма.
Полез доставать скелеты из шкафа.
Две основных таблицы TABLE_ORDERS и TABLE_ORDERS_PRODUCTS. Из индексов — только праймари. Причем ни одного поля из TABLE_ORDERS_PRODUCTS, в этом запросе не используется. Смотришь план — а там перебор 100К х 30К записей через filesort и temptable.
Собственно запрос, для ценителей. $products_query_raw = "select distinct o.orders_id, o.point,o.orders_status, o.customers_name, o.customers_city, o.customers_street_address ,
o.customers_telephone, o.customers_id, o.payment_method, o.date_purchased, o.last_modified, o.currency, o.currency_value, s.orders_status_name
from " . TABLE_ORDERS_STATUS . " s, " . TABLE_ORDERS . " o
inner join " . TABLE_ORDERS_PRODUCTS . " op on (o.orders_id = op.orders_id)
where o.orders_status = s.orders_status_id
and o.point<> '".$pzstore."'
and UNIX_TIMESTAMP(o.date_purchased) > $startDate
and UNIX_TIMESTAMP(o.date_purchased) <= $endDate
and Hour(o.date_purchased)*60+Minute(o.date_purchased) > '".intval(date("H",$startDate)*60+date("i",$startDate))."'
and Hour(o.date_purchased)*60+Minute(o.date_purchased) <= '".intval(date("H",$endDate)*60+date("i",$endDate))."'
group by o.orders_id
order by o.date_purchased DESC";
Ну и само собой, запрос прогоняется два раза, посчитать строчки и получить данные.
А потом в цикле пробежка по результатам, на каждую строчку выдачи рожается объект «заказ», в который вычитываются данные (снова!) из базы, и пересчитывается сумма (сумма то заказа нигде не хранится). Складывается все в массив, который потом сортируется и выдается.
Только вот на этом лучшем решении всех времен и народов, матерые студии почемуто не могут сделать довольно простые и логичные вещи.
Я не говорю что все плохо, но первое место вызывает некоторый когнитивный диссонанс.
А с битриксом все довольно просто.
Торговая марка раскрученная.
Натаскиваешь дешевого, малоопытного разработчика, который начинает клепать эти пресловутые «инфоблоки» и получаешь профит.
Правда битрикс подходит для довольно ограниченного круга типовых задач и любая попытка сделать чтото не совсем стандартное выливается в вагоны времени и килограммы головной боли.
Да и реализация кой-каких типовых веще вызывает некоторое недоумение.
Но это ведь уже другая история :)
Все вышенаписанное — сугубо мое личное мнение, на объективность не претендую.
В догонку
А еще с тэгами бывает фигня с кодировками.
Поставил Клементин, попробовать, и половину композиций он вывел кривулицей.
А вышеупомянутый Apollo их показывает нормально.
> удобнее пользоваться тегами.
На вкус и цвет — фломастеров нет. Мне например неудобно.
И у меня далеко не у вся музыка с тэгами, тратить время на исправление — откровенно жалко. Кинул в папку — и все.
Поэтому я плюнул на фубар и иже с ними, пользуюсь Apollo несмотря на то, что он не уже развивается.
А то, что в нем нет всяких красявостей и прочих свистоперделок — это даже плюс.
Интересная штука, есть фришная лицензия.
Номенклатура 30000+
Цена на позицию из разных партий в разных точках — разная.
И обновляется довольно часто.
XML выгрузка получается ну просто совсем неприличных размеров.
В результате отказались от Битрикса.
Правда источник данных — не 1С.
Ну и в рот его занести не такая большая сложность.
И испарениями надышаться — нефиг делать.
Абразивная поверхность на спичечном коробке — красный фосфор с абразивной пылью (например стекло) итд.
При возгонке — получается белый фосфор, который быстро окисляется, отсюда и дымок и свечение.
Летальная доза белого фосфора для взрослого мужчины составляет 0,05—0,1 г.
Только дополненная и переработанная командой «профессионалов».
Там весь проект — яркий пример «никогда так не делай».
white-space: pre-wrap;
Ну вот откуда подгреблись эти лишние переводы строк?
Есть такие затейники.
Недавно попался очередной перл подобных ЦМСостроителей.
Простой отчетик по заказам на сайте, вначале месяца формируется еще терпимо, к концу месяца начинает тупить минут по 10 (если не обламывается по лимиту памяти). На выдаче у него от силы 3К строчек, типа №/Датавремя/Покупатель/Точка продажи/Сумма.
Полез доставать скелеты из шкафа.
Две основных таблицы TABLE_ORDERS и TABLE_ORDERS_PRODUCTS. Из индексов — только праймари. Причем ни одного поля из TABLE_ORDERS_PRODUCTS, в этом запросе не используется. Смотришь план — а там перебор 100К х 30К записей через filesort и temptable.
Собственно запрос, для ценителей.
$products_query_raw = "select distinct o.orders_id, o.point,o.orders_status, o.customers_name, o.customers_city, o.customers_street_address ,
o.customers_telephone, o.customers_id, o.payment_method, o.date_purchased, o.last_modified, o.currency, o.currency_value, s.orders_status_name
from " . TABLE_ORDERS_STATUS . " s, " . TABLE_ORDERS . " o
inner join " . TABLE_ORDERS_PRODUCTS . " op on (o.orders_id = op.orders_id)
where o.orders_status = s.orders_status_id
and o.point<> '".$pzstore."'
and UNIX_TIMESTAMP(o.date_purchased) > $startDate
and UNIX_TIMESTAMP(o.date_purchased) <= $endDate
and Hour(o.date_purchased)*60+Minute(o.date_purchased) > '".intval(date("H",$startDate)*60+date("i",$startDate))."'
and Hour(o.date_purchased)*60+Minute(o.date_purchased) <= '".intval(date("H",$endDate)*60+date("i",$endDate))."'
group by o.orders_id
order by o.date_purchased DESC";
Ну и само собой, запрос прогоняется два раза, посчитать строчки и получить данные.
А потом в цикле пробежка по результатам, на каждую строчку выдачи рожается объект «заказ», в который вычитываются данные (снова!) из базы, и пересчитывается сумма (сумма то заказа нигде не хранится). Складывается все в массив, который потом сортируется и выдается.
Я не говорю что все плохо, но первое место вызывает некоторый когнитивный диссонанс.
Ну он ведь первый в рейтингах.
Ну это же 1С.
Мне про него рассказали — там все круто и все можно сделать легко и быстро.
Торговая марка раскрученная.
Натаскиваешь дешевого, малоопытного разработчика, который начинает клепать эти пресловутые «инфоблоки» и получаешь профит.
Правда битрикс подходит для довольно ограниченного круга типовых задач и любая попытка сделать чтото не совсем стандартное выливается в вагоны времени и килограммы головной боли.
Да и реализация кой-каких типовых веще вызывает некоторое недоумение.
Но это ведь уже другая история :)
Все вышенаписанное — сугубо мое личное мнение, на объективность не претендую.
А еще с тэгами бывает фигня с кодировками.
Поставил Клементин, попробовать, и половину композиций он вывел кривулицей.
А вышеупомянутый Apollo их показывает нормально.
На вкус и цвет — фломастеров нет. Мне например неудобно.
И у меня далеко не у вся музыка с тэгами, тратить время на исправление — откровенно жалко. Кинул в папку — и все.
Поэтому я плюнул на фубар и иже с ними, пользуюсь Apollo несмотря на то, что он не уже развивается.
А то, что в нем нет всяких красявостей и прочих свистоперделок — это даже плюс.