Decadal: да, я был не прав. Два раза. Вот этот индекс даст прирост скорости на выборке
ALTER TABLE B ADD INDEX `idx_B_type_price_a` (`type`, `price`, `a_id`);
SELECT `A`.*
FROM A
WHERE EXISTS (SELECT B.id FROM B WHERE B.a_id = A.id AND B.price=25 AND B.type=1)
AND
EXISTS (SELECT B.id FROM B WHERE B.a_id = A.id AND B.price=20 AND B.type=0)
;
SELECT `A`.*
FROM `A`
LEFT JOIN `B` ON `A`.`id` = `B`.`bid_id`
WHERE
(B.price_unit >=10 AND type=0)
OR -- тут надо OR
(B.price_unit >=100 AND type=1)
GROUP BY `id` -- группировка по id в какой таблице?
О, какой ужас, какой ужас! Правильно заданный вопрос = половина решения (не твой случай), неправильно заданный = Сусанин (ты) повёл немцев (нас) лесом из Москвы в Питер через Владивосток. Может ты переоформишь свой вопрос, указав реальные таблицы и данные?
Kekoc: без разницы - одна или две таблицы, особенно если они идентичные по структуре. Без реального примера, без реальной модели данных, мне кажется, мы тут обсуждаем сферических коней в вакууме. О чём был вопрос, по существу? О каких сущностях идёт речь?
killbond: ещё вариант популярный - делить приложение на "админку" и "юзерку" по поддоменам или префиксам путей. JS для приложения в этом случае можно собрать в два файла (app.js и app_admin.js). На юзерке один, на админке другой. Когда пользователь переходит из одной части в другую, страницу перегружать и выдавать другую версию JS. Ну и на сервере конечно проверять - есть ли права на админку, то есть можно ли ему отдать app_admin.js
killbond: Ну тогда такой вариант: устанавливай специальную куку, а потом проверяй в nginx. Можно использовать хэшированную куку, а в nginx реализовать проверку через пару строк на встроенном интерпретаторе Perl.
80% времени мы действительно тратим на чтение и анализ кода, 20% на написание.
commit diff бывает всего пару строк содержит, а за ними кроются часы.
Подход такой: если для проверки чего-то пришлось написать какой-нибудь кусочек кода с echo или var_dump, то можно попробовать зафиксировать этот проверочный набор данных и результаты в виде интеграционного или модульного теста, чтобы в будущем не проверять то же самое ещё раз.
Одностраничные сайты и сайты визитки до сих пор могут быть созданы таким образом, что кроме HTML и CSS больше ничего не используется. Ещё есть специальные генераторы статических сайтов, чтобы публиковать очень редко изменяемый контент, например тексты книг.
А более сложные используют базы данных, например MySQL.
При этом у сайта есть как минимум
* страница, на которой есть форма ввода, в которой можно ввести текст статьи, а затем сохранить на сервере в базе данных
* страница, на которой можно посмотреть текст статьи
* страница, на которой можно посмотреть список статей, например в порядке убывания даты создания
Алекс Глебов: был SSI и CGI. Большие сайты всё равно хоть через задний проход но формировались автоматически. Не было такой интерактивности, но были сайты с количеством страниц > 500. Слишком много чтобы всё это делалось вручную.
Иван М: нанять двух кандидатов как будто бы для собеседования и дать им прособеседовать друг друга. Кто кого завалит, тот и выиграл. Code Battle! Поставить камеру, транслировать в интернет. Я пошёл за попкорном :)