Выполнение скрипта после перехода через адресную строку?

Разве ModRewrite можно подключить скрипт для выборки из базы данных?

Hyt: ModRewrite - это всего лишь ужасный способ организации разбора URL (еще его иногда, не менее ужасно, называют ЧПУ)
Нет, htaccess не будет ничего никуда подключать. Что вы можете сделать с его помощью (напомню, сделать ужасно) - это привести запрос www.example.com/script1 к представлению www.example.com/path/to/my/script1.php
или, что немного менее ужасно, но все еще ужасно, к www.example.com/index.php?action=script1

Видимо, у вас в голове есть какая-то идея, сформулировать которую у вас не получается. Поверьте, единственно верное решение этой задачи - взять, если не фреймворк, то компонент роутинга, попробовать сделать что-либо с его помощью, потом попробовать с его помощью решить именно вашу задачу. И если что-то не получается конкретно, то задавать вопрос по конкретному компоненту (Mackaw router, symphony router etc...)

Виктор Ablebeam: Эм, а в чем проблема чпу и фронт-контроллера?

He11ion: В названии и в реализации.
В ЧПУ плохо и то и другое: и название бредовейшее и несвязанное с действительностью, еще и реализуется через htaccess - чем плох htaccess, если можно, не буду объяснять

Паттерн фронт контроллера сам по себе ничего плохого не сделал и в той или иной степени он используется, наверное, всеми диспатчерами. Однако, изобретать его самому - это очень плохо (когда видишь статьи на хабре, что кто-то изобрел новый супер-быстрый роутинг на XML, а другой - кладет файл с роутами возле каждого контроллера, и т.д. и т.п.)

Вот поэтому лучше сразу использовать (смотреть как устроены) готовые компоненты или фреймворки.

Виктор Ablebeam: Чем плох htaccess? Я, например, использую nginx и у меня нету htaccess, а чпу с роутингом есть - какие проблемы в этом случае?

He11ion: 1. Сами ответили - htaccess - это частное решение для апача. Не все пользуются апаче. Не везде есть апач. Не всегда апач - лучшее решение.
2. Роутинг - это прерогатива приложения. Роутинг на уровне веб-сервера - это ненужное разделение кода приложения. PHP еще только учится этому, потому не любой код можно запустить на встроенном вебсервере без громоздких LAMP-стэков.

Виктор Ablebeam: Серьезно? Ненужное? А ничего что бекенд(php) на порядок медленнее, чем nginx, скажем? И что роутить конфигом nginx/htaccess-ом сильно быстрее и лучше, чем скриптами? Ну а про "частное" решение - так и php код не запустится на node, напрмер, это же не повод его не использовать

He11ion: O.o
Когда разговор заходит о "быстрее" и "пхп", у меня аргументы заканчиваются) "Скорость" нужно измерять профайлером, только тогда, когда это необходимо и сравнивать относительно приложения, а не в вакууме.

Про ноду - вообще не в ту степь. Если разговор идет на таком уровне, то вот аксиома:

В сколько угодно сложном приложении (если это приложение, а не сайт-визитка, скрипт и т.д.) роутинг должен быть частью диспатчера, а диспатчер - частью приложения тчк.

Виктор Ablebeam: Ладно, полагаю тут взаимонепонимание. А скорость можно замерить просто временем ответа сервера.

He11ion: Определенно, временем от сервера. Но увеличивать производительность роутинга - это экономить на спичках, за счет существенного падения в скорости разработки.

Я не могу себе представить случай, когда роутинг был бы узким местом. И даже в таком случае, можно свести практически к нулю его зависимость от языка - так делается в случаях с "агрессивным" кешированием в множестве фреймворков.