Круто! На одном из балкончиков сушаться чьи то трусы с красной и зеленой прищепкой ) Париж намного качественней и хром под убунтой не вылетает (тут дело в мунлайте конечно)
1. Кросдоменный аякс-запрос — и как его сделать, без доступа к файлам на сайте клиента? А объяснять клиенту что и куда положить — никто с этим возиться не будет.
2. Если у нас есть доступ к сайту клиента — проблем нет!
3. Виджет должен быть в ифрейме, а размеры ифрейма фиксированы — в этом то и проблема.
Спасибо за ответ, но то, как вы это написали работать не будет.
Кому нужно это как приложение, пока у нас нет ДОСТАТОЧНОГО числа зарегистрированных компаний. Вот как наберем компаний побольше, тогда и сделаем главную страничку, ориентированную на клиентов.
Какое решение проблемы? Придётся создать избыточный индекс и держать одновременно (a) и (a, b)
А чем не устраивает (a) и (b)? — В отличие от вашего варианта мы получим еще и оптимизацию при поиске по ключу b и экономию места на ключах (последнее конечно спорно). И версия у вас 5.1.45 и статья в плюсах… Кучу народа в заблуждение введет! Хабр уже не торт (
А если у меня 5 полей в таблице и есть необходимость искать строки по совпадениям различных пары, троек значений — это мне нужно создавать все возможные пересечения индексов? например (a,b), (a,c), (c,d), (a,c,d) — как то это очень странно. В моем примере видно, что на скорость выполнения запроса не влияет и замечательно используется index_merge
Мат в статье — это теперь так модно?
2. Если у нас есть доступ к сайту клиента — проблем нет!
3. Виджет должен быть в ифрейме, а размеры ифрейма фиксированы — в этом то и проблема.
Спасибо за ответ, но то, как вы это написали работать не будет.
А если кто то нарисует свой телефон на фоне кирпича — это тоже черный пиар по отношению к iPhone?
А партнерская программа — идея хорошая, да.
А чем не устраивает (a) и (b)? — В отличие от вашего варианта мы получим еще и оптимизацию при поиске по ключу b и экономию места на ключах (последнее конечно спорно). И версия у вас 5.1.45 и статья в плюсах… Кучу народа в заблуждение введет! Хабр уже не торт (
В примере в статье автор создал составной индекс и дропнул одиночный. А потому удивляется, куда же делась производительность.
индекс на полях currency_id и transaction_type
[accounting_user]>select count(id) from ledger where currency_id = 1 and transaction_type = 'invoice';
+-----------+
| count(id) |
+-----------+
| 13197 |
+-----------+
1 row in set (0.04 sec)
[accounting_user]>explain select count(id) from ledger where currency_id = 1 and transaction_type = 'invoice';
+----+-------------+--------+-------------+------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+-------------+------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
| 1 | SIMPLE | ledger | index_merge | currency_id,transaction_type | transaction_type,currency_id | 1,4 | NULL | 3749 | Using intersect(transaction_type,currency_id); Using where; Using index |
+----+-------------+--------+-------------+------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
1 row in set (0.05 sec)
добавляем индекс на (currency_id, transaction_type)
запрос отрабатывает те же 0.04 сек
[accounting_user]>explain select count(id) from ledger where currency_id = 1 and transaction_type = 'invoice';
+----+-------------+--------+-------------+-------------------------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+-------------+-------------------------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
| 1 | SIMPLE | ledger | index_merge | currency_id,transaction_type,transaction_type_2 | transaction_type,currency_id | 1,4 | NULL | 3764 | Using intersect(transaction_type,currency_id); Using where; Using index |
+----+-------------+--------+-------------+-------------------------------------------------+------------------------------+---------+------+------+-------------------------------------------------------------------------+
1 row in set (0.00 sec)