Клиент: Хочу Мэйл РУ + вики + поиск за 20К

Значит у победителя не все так просто :)

Потому, что у тендеров есть достаточно четко прописанные правила игры.

Возможно тот тендер, которым у Вас махали перед носом был уже недействителен по тем или иным причинам.

Если втаскивают, то обычно это как-то мотивируют.

Завидую Вам :)

Может быть есть смысл сначала понять что реально происходит с тендером.... потому, что возможна ситуация, когда у них просто нет реальных исполнителей и они просто пытаются сбить цену. Второй вариант аналогичен, но генподрядчик пытается опосредованно найти исполнителя. Пока Вы не подписали никаких договоров и не давали письменных коммерческих предложений у Вас развязаны руки.

Не факт. Иногда на таких продуктах действительно проще и дешевле делать многие нестандартные вещи.

Например - объем данных в библиотеке будет сосавлять пару терабайт :) Или у людей уже есть купленный оракл, но вот применить его по каким-то причинам ни к чему не могут.

Знаю реальный случай когда было закуплена пара десятков AS400 для системы документооборота и внутреннего учета. Серваки, каждый по поллимона вечнозеленых были куплены, установлены, а вот систему документооборота на них так и не внедрили. В результате около года сервачки стояли незагруженные. Потом на них, наконец, подняли внутреннюю почтовую систему и, таки, планируют развернуть другую систему документооборота.

А скорее всего заказчик уже использует другие системы на оракле и не хочет плодить зверинца из платформ.

Скорее всего так и происходит. Я в самом начале не совсем корректно описал задачу поиска. Так вот, поиск идет по 20К статьям и 50 млн внешних документов. То есть, придется понять как отранжировать просто текстовые файлы с приоритетом по отношению к внешним страницам, заточенным под Вэб. Это совершенный нестандарт, здесь им не помогут многие Ораклевые спецы. Нужно понять алгоритм ранжирования. Плюс к этому гимор с согласованиями, плюс третья сторона, ведущая и заполняющая БД, причем доступ к Базе есть только у них, и никто нам самим не даст и одной таблички добавить.

Итого получаем полноценный головомой, тратим три месяца, ждем подписанных бумажек, время тикает, зарплата и аренда платится и так далее.

И двадцатка эта превращается (превращается, превращается.....) в минус тридцать.

Тогда можно сидеть на попе ровно и ждать пока клиент созреет до Ваших условий :)

Работу можно смело бить как минимум на 3 этапа, причем по каждому из них можно смело брать деньги.

1. Разработка архитектуры системы и принципов ранжирования документов.

2. Разработка ТЗ на API, который будет писать третья сторона. При этом надо оговорить, что Вы не несете ответственности за API, и при изменениях в системе API должен быть неизменным. Т.е. Если есть процедура GetText c двумя входными параметрами, то после изменения внутри системы процедкра должна работать так же. максимум, можно добавлять в процедуру опциональные дополнительные параметры.

3. Непосредственно сама разработка, с учетом уже существующего и отлаженного API.

Так предоплату в размере 30% под банковскую гарантию еще никто не отменял в гостендерах :)

И полтинник в Вашем случае - это действительно себестоимость или даже демпинг.

Удачи.

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

различного типа ODBC_JDBC бриджей, ADO.NET и тому подобного.

Сохраненные процедуры, таблицы баз данных являются полноценными об'ектами

базы данных и их примение или не примение определяется разработчиком/архитектором системы.

Применение процедур не имеет никакого прямого отношеиня к безопасности приложения.

Решение-же бизнес задач сохраненными процедурами не является об'язательным.

И если уже есть приемлиемые решения без применения процедур то переделка этих решений на процедуры не всегда оправдана.

Что-такое "оракловая система" которая может развиваться и меняться просто так, сама по себе?

pelvis, По существу-же топика, заказчик сам не вполне представляет в техническом плане что он хочет.

Задача очень интересная, и если хватит терпения и умения то отдача от этого проекта даже при минимальных финансовых прибылях будет ощутимой. Сколько вы знаете команд кто успешно

справлялся с подобным проектом?, да и кормить в случае успеха будет не один год.

qList, здесь, как бы, проблем то нет. Вопрос в сроках и нагрузках. Банально, но факт: Оракля очень хорошо индексирует малое кол-во документов, да и большое тоже. Но как только начинаешь перестраивать индекс, он сразу дает о себе знать. Чуть ошибся - паши опять, лей траф.

А все это сказывается на дальнейшем развитии, равно как и интересе в конкретном заказе.

Отвечаю анониму: меня интересует, точнее интересовала стоимость каждого из блоков ТЗ. Спасибо Мэкс за то, что направил в нужное русло.

pelvis, Если это об'яснить заказчику, то он может и поймет, пусть и не сйчас а попозже. А потом можно и за переработку браться. Не всегда получется сделать хорошо с первого раза. И многие заказчики понимают.

qList, Ваши слова, да Богу в уши :)

Здесь речь идет о том, что мне быстрее коки-наки открутят, прежде чем я успею переделать за их счет.

pelvis, не вижу, в чем заключается проблема, если нет возможности реализовать, то и браться не надо, пусть покупают себе решение от Яндекса, оно им будет делать все, что надо, в плане поиска.

"Пользователь должен видеть только то, что ему разрешено видеть".

Поясняю - Стандартный селект с джойном из 5-6 таблиц.

В результате - выводятся таблица всего в 5-7 колонок. А каждая таблица может содержать и другие, совсем не предназначенные для просмотра этим пользователем данные. Но он, составив правильно запрос, в Вашей модели безопасности, может их получить. Более того, злоумышленник сможет получать из этих таблиц данные совсем к нему не отоносящиеся.

В модели с API мы явно запрещаем пользователю доступ к таблицам, но разрешаем - к процедурам. В этом случае мы полностью контролируем то, что мы выдаем пользователю.

В данном конкретном случае она на 100% оправдана. Это интеграционное решение. Причем, насколько я понял, уже существует система, к которой Олегу надо прикрутить дополнительные сервисы, причем не затрагивая архитектуры самой системы. Такие требования бывают, как правило, в случае, когда саму систему планируют развивать дальше. А дальнейшее развитие, с очень высокой вероятностью, подразумевает изменение структуры данных, например введения дополнительнх справочников.. Следовательно, такое развитие предусматривает и паралельное внесений изменений в сервисы Олега. Именно паралельное... иначе все перестанет работать. Наличие четкого прописанного API решает проблему синхронной модернизации системы. Т.е. можно развивать каждую из подсистем отдельно, не при этом не трогая API, и внося в него соответствующие изменения каждый со своей стороны.

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

Это миф. Если система не устроит заказчика, он просто остановит развитие проекта и начнет заново с другой командой. Если все делать профессионально, то должно получаться хорошо с первого раза, и в дальнейшем заказчик будет самостоятельно сопровождать систему, заказывая только новый функционал. Переделки - это просто пустая нервотрепка. Гораздо проще изначально максимально правильно поставить задачу, сделать прототип, наконец.

Мы, таки, бизнесом нанимаемся, или делим весь мир на черное и белое? :)

Топик изначально был не о возможности создания системы, а об оценке трудозатрат на такую систему, и как следствие, справедливой цене работы.