Лень догадываться, что у Вас за СУБД - из вопроса не видно.
В общем случае, один из вариантов решения такой задачи можно искать вот в этом направлении:
SELECT t1.P1, t1.P2, t1.P3 FROM MyTable t1 INNER JOIN (SELECT P1, MAX(P2) AS maxP2 FROM MyTable GROUP BY P1) t2 ON (t2.P1 = t1.P1 and t2.maxP2 = t1.P2)
Зависит от серьезности заказчика и важности портала в бизнес-процессах заказчика. Заказчику, который ориентируется на перспективу, на развитие, намного более интересно иметь полные права на свой продукт. Здесь все просто: ни один серьезный продукт не делается в один этап. Со временем появляются потребности в доработках, переработках функциональности. А представьте, что после какого-то этапа заказчик поссорился с автором движка и при этом заказчику не переданы права на исходный код? Что делать? Найти другого разработчика относительно несложно. Но адекватный разработчик не захочет ловить рыбу в мутной водичке (ковыряться в движке, на которой нет права). Кроме того, велика вероятность, что нет не только прав на движок, код, модификацию, но и нет толковой документации. Скорее всего он предложит перенести систему на свой движок или разработать движок с нуля (а это стоимость, сроки и т.д. - лишние траты для заказчика).
Здесь вы можете пойти по политике лицензирования (но это уже не заказная разработка). Т.е. Вы разработали некий коробочный продукт, или платформу. Тогда вы сможете зарабатывать на трех направлениях:
а) Продажа лицензий;
б) Интеграция продукта в инфраструктуру заказчика (включая дополнительные работы по добавлению новой функциональности);
в) Платный саппорт.
Из этого лицензии, при определенных условиях (не всегда), могут быть поставлены на учет как нематериальный актив и увеличат капитализацию компании. Иногда работы по интеграции, если они формируют цельный продукт тоже могут формировать актив. А остальные затраты заказчика = прямые расходы.
Кроме того, убедить заказчика на такую схему тоже не просто:
- надо неплохо раскрутить свой бренд;
- лицензия должна позволять заказчику вносить изменения в исходный код;
- надо иметь не просто хорошую, а превосходную документацию своего движка, доступную другим разработчикам, чтобы заказчик в случае необходимости мог привлечь другого исполнителя и много, многое другое.
Здесь нужно совсем иначе позиционировать компанию и ее услуги на рынке.
Пробуйте. Вот Вам примеры: Микрософт, Оракл, SAP и тысячи других используют подобный подход. Да взять ту же 1С или Битрикс.
Много очень холиварных моментов.
От себя дополню вот такими замечаниями:
1. Заказывая собственную разработку, чаще всего проще решаются вопросы с правами на продукт (авторские, смежные, эксклюзивные, неэксклюзивные - все можно грамотно в договоре предусмотреть). Продавая один движок во много рук, все права каждому не передашь.
2. Следствие п. 1 - продукт может быть поставлен на учет, как нематериальный актив. И эти миллионы рублей - не расход! Такой продукт увеличивает капитализацию компании. В дальнейшем такой продукт может быть сравнительно легко продан правообладателем, заложен в банке, сдан в аренду и т.д.
Часто не до конца понимают различия между "тупым распилом" и увеличением капитализации - цели у них, все же, разные.
Перевод местами хромает:
postavkin, вопрос не до конца понятен, но предположу, что то, что Вы ищете: http://www.php.net/manual/ru/language.variables.variable.php
$$name = array();
Только рекомендую еще 10 раз подумать перед применением этого, ибо вероятно изначальная ошибка в архитектуре, раз такое требуется.
Отлично, спасибо!
Есть небольшое замечание: со страницы форума (список тем) ссылки на темы почему-то всегда формируются с параметром goto=newpost. И прочитанные и непрочитанные. Это очень неудобно, особенно в больших темах, которые еще не читал - приходится много откручивать наверх. См. скрин.
Ну и + совсем порезали вывод сведений об авторе - сильно узнаваемость автора упала. Раньше был аватар, звание, дата реги, откуда, кол-во сообщений... Сейчас совсем ничего - только ник. И довольно сложно понять, где чья реплика в треде. Раньше боковым зрением как-то автоматом получалось выцепить автора. Попробую привыкнуть.
я, может, не понял условия задачи, но, для чего регулярки, если есть специальная функция? http://ru2.php.net/manual/ru/function.strip-tags.php
humbert, для ускорения поиска по параметрам можно попробовать так:
1. делайте отдельную таблицу сочетаний параметров combinations с полями:
id_combination|category|color
2. заполняйте ее всеми возможными, встречаемыми комбинациями (id_combination - автоинкремент).
3. в таблицу объектов добавьте поле-ссылку на нужную комбинацию параметров (id_combination).
Ну, грубо: id_object|name|desc|id_combination
Что дальше делать, думаю, понятно.
----
Сорри, стормозил. Не заметил, что категорий и цветов может быть одновременно несколько. Тогда стабильное решение - то, что в 3-м посте. По поводу тормозов надо смотреть план выполнения, может где индексов не сделали. Либо менять движок СУБД, либо наращивать железо, но это слишком банально.
Проще всего, наверное, пойти по такому пути:
SELECT 0 AS sorder, id, field1, fieldN FROM table1 WHERE id=3 UNION ALL SELECT 1 AS sorder, id, field1, fieldN FROM table1 WHERE id<>3 ORDER BY sorder ASC, id ASC
На сколько я еще помню Firebird, запрос должен выглядеть как-то так (FB >= 1.5):
SELECT SUM( CASE WHEN id_sotr = 1 THEN zp ELSE 0 END ) AS SUM_1, SUM( CASE WHEN id_sotr <> 1 THEN zp ELSE 0 END ) AS SUM_2 FROM Table_1
НО! Нужно смотреть план запроса и сравнивать его с планом двух простых запросов (тут неизвестно, что будет быстрее - у FB весьма хитрый оптимизатор).
