rPman

Пожалуйста, умоляю, не делайте постраничную выборку… всеми силами избавляйте пользователя от постраничного сканирования… это сложно/медленно для сервера (недавно анализировал очередной высер для распила госбюджета — выборка записи из справочника из 13т. записей 1500 страниц… кому такой бред нужен, кстати тормозит по 3 секунды на любой пшик)

Любой выбор больше 10-20 записей должен быть исключен (на самом деле можно потерпеть и 100… но больше значит где то забыли сделать возможность указания критерия выбора), там где это возможно — введением категорий, и в любом случае сделать полнотекстовый поиск-фильтр для данных с максимальной информативностью о результатах.

Выбор адреса — вообще классика, как только разработчики не изгаляются (сам помню извращался со сложной активной формой меняющей фильтр в полях выбора и их отображение). Пусть выводится полная строка из базы КЛАДР (страна, область, район, город/село, улица), а поиск полнотекстовый сразу по всем полям.

заказчику можно ответить в следующем ключе:
* цены специалистов java и usual web (кстати python так же для web несколько не в ту степь)
* наличие собственных специалистов (это из разряда, а за каких специалистов уже заплачено)

p.s. для разработки проекта, почти пофиг, какую платформу выбрать, хоть на лиспе пишите, но существуют некоторые устоявшиеся принципы, паттерны разработки, под задачи, в вашем случае это web. Может быть ощутимо выгоднее будет реализовать сначала проект на том, на чем дешевле (хоть тот же php, уж тут 'специалистов' проще всего найти), а затем, получив работающий проект, на котором отполировано ТЗ, повторить его на чем-то более адекватном задаче.

Если по каким то причинам не устраивает одна таблица (хотя, изучите такие вещи как кластеризация), то можно автоматически по структуре БД для каждой таблицы создать парную, заполняемую триггерами, при этом логику заполнения для разных таблиц можно варьировать — для одних хранить только факты добавления и удаления, для других добавить факты модификации, для третьих может понадобиться факты чтения данных (эти данные можно и не триггерами заполнять), где то можно вообще полный лог изменений данных (сохранять изменившиеся полей для истории изменений)…

Проблема потом интерпретировать эти данные… но, возможности, которые обеспечивает такой подход, очень велики.

это феерично! что именно вы хотите в таком случае от фреймворка?
* первая страничка — зависит от выбора серверной части, но в конечном счете без фреймворков это 5-6 строчек кода!
* вторая страничка — картинка меняющая прозрачность? это в css делается, какие фреймворки? доступ к железу изменяющему яркость света? опять таки от него зависит, но по любому еще 5 строчек кода.