@DmitriyEntelis: Об этом и говорил. Продуктивность сильно упадёт. В моем комменте статья с живым примером этого. Да и управление всей этой бедой будет просто кошмарное. Проще развернуть API к такой базе и пользоваться только им чем администрировать такую базу.
В том то и дело что быстрее будет процедура. Особенно если сборщик запроса вы соберёте на си и экспортируете его в базу. Т.к. стандартные средства бд оставляют желать лучшего. Хранимая процедура будет собирать запрос, выполнять его и выдавать результат. А вью - это лишь хранимый запрос. И чем сложнее этот хранимый запрос, и чем больше данных в нём (строк) тем больше ресурсов потребуется для выборки из этой вьюхи. В конце концов вью - это не таблица и соотв. нет индексов.
Смысл остаётся тем же. Вы собираетесь собрать геморрой. Впринципе можно было бы собрать такое допустим до 100 пользователей. Но больше... чистой воды мазохизм.
@malan: это полный бред. В конце концов ваши запросы к VIEW выглядят так SELECT * FROM (SELECT ... ) ...
Только при рациональном использовании субселектов, в субселекте (вашем view) должно быть минимум данных а у вас их там сотни а может даже и тысячи. Вы заставите сервер выполнять лишнюю работу т.к. те же данные проще и быстрее перелопатить одним запросом. А если вы еще захотите выполнить JOIN на двух view? Бедный сервер.
View не решат никакой проблемы с безопасностью. Безопасность обеспечивают права пользователя бд. А он у вас один. И если кто-то найдёт возможность кидать запросы к базе он не будет смотреть ваши 10 000 view`х. Он полезет к таблицам.
Советую поискать обзоры по join`ам вообще и по join`ам в mysql в частности. Join - это соединение наборов данных. В ON и USING указывается точка соединения этих наборов (по какому принципу и полям мы соединяем и расширяем эти наборы данных). А фильтрация результатов идёт в WHERE и HAVING(в последнюю очередь). В данном случае вы добавили фильтрацию не туда.
Начнём с того что это не запрос. Это конструктор части тела запроса. Неужели сложно сделать дамп запроса перед отправкой в дб. А так, если этот джоин единственный, то будет проще переложить по моему варианту. И все ваши проверки плавно переместятся в WHERE.
... WHERE price.post_id = posts.ID AND price.meta_key LIKE \'%_to_price_%\' AND price.post_id = '1050' и т.д.
И вообще топик не в той теме. Это не про php. И не понятно с какой БД мы имеем дело. Если мы имеем дело с MySQL, то:
In MySQL, JOIN, CROSS JOIN, and INNER JOIN are syntactic equivalents (they can replace each other).
Таким образом можно сделать как я указал, и это будет правильно, нежели пихать всё подряд в параметры соединения таблиц.
Кстати у svgweb есть ещё один плюс - его можно связать например с jQuery. Хотя с таким сращиванием в свое время поседел пока разобрался. Но это возможно.
нет. просто именуешь элементы векторного изображения в редакторе. вроде в кореле работает и выгружаешь как SVG. А потом в тело SVG вставляешь скрипт.. принцип такой же как и в HTML.
И для каждого элемента SVG где нужно добавляешь обработчик события onmouseover и onmouseout. И в обработчике просто стиль меняешь на другую заливку. Или просто через стили. Но стили не в атрибуте style="..." элемента не будут обрабатываться в svgweb. Это что касается кросбраузерности.
Для современных браузеров будет отображаться чистый SVG а для пользователей старых иешек визуализороваться SVG будет через FLASH.
@Zewkin: Согласен. Я не раз связывался с автором для получения решения. Но когда разобрался полюбил этот мод. Я с его помощью вообще делаю управление таблицами бд своих модов. Поверьте, это куда быстрее чем ковырять обёртку ExtJS под Modx. И отсутствие документации вполне обосновано - MIGX настолько всеобьемлющий модуль, что мануал по нему должен быть минимум в четверть от мануала самого MODX. Можете написать на почту в чём загвоздка - постараюсь помочь. (ugod@yandex.ru)
Абсолютно согласен. Скорее всего MySQL вернул ошибку. Скорее всего как раз в этом месте ошибка. Передавайте в функцию $ids в виде массива и там уже проверяйте на длину массива а для формирования строкового $ids используйте implode().
Таблица корзины:
покупатель(ид)
товар(ид)
аттрибуты(строка, с перечислением атрибутов)
количество
и уникальный или первичный ключ на первые три поля