Зачем добиться? Уже есть, но ничего особо хорошего в этом занятии нет. А вот как раз в консалтинге - да, хотелось бы добиться. Проблема в нахождении контрактов, и пока что единственный работающий способ - прошлые работодатели, или через людей, с которыми работал раньше.
Не, я делал проще. Поверх готового Оракла. Вывод получается в том, что делать поверх готового Оракла - медленно.
Вопрос был - ЗАЧЕМ 
Второй вопрос (раз всё-таки после интербейса) чем не подходили BLOBы для данной задачи ?
Блобы - это механизм хранения сырых данных. Поверх которого нужен слой для организации метаданных (директории, ассоциация блоков в файлах). Э-э-э уже не помню, делал ли я поверх блобов или поверх простого varchar(1024). Но по скорости оно вышло примерно в 100 раз медленнее простой файловой системы, еслия правильно помню. Видимо, Оракл еще и sync’ил на диск старательно.
А зачем - поиграть, интересно, надо же развивать мозги. На одной из работ на самом деле как-то была производственная потребность, чтобы перекладывание данных между базой и файловой системой делалось без возможности потерь.
Какие, извините, “ассоциации блоков” если файл = блобу по определению, и все труды по дефрагментированию и ассоциированию автоматом ложатся на БД. И “директории” в оракле реализуются на ура - это же всего-лишь группировка файлов, так-что банальной ОДНО таблички parent/child/childtype (где childtype либо dir либо blob) по уши хватает. Думаю Вы действительно изобретали велосипед с varchar(1024). Весь вопрос - зачем, и если ответа на него нет, то возникает подозрение, что по работе делать было нечего, а на что-то более умное не хватило сил … поскольку это подозрение не особенно полезно для Вашего резюме, я бы сделал выводы
Недопонял - база данных находится в файловой системе. Если надо контролировать сохранность выгрузки из БД это делается контрольными суммами, в “худшем” случае перечитыванием (линейное замедление записи в два раза), в “худшемсупернадёжном случае” - выгрузкой трёх копий с перечитыванием и перезаписыванием не совпавшей копии содержимым совпавших ( пользуясь случаем передаю привет амазону )
Ну да, директории - одной табличке. И во второй табличке - атрибуты, и в третьей - собственно блоки данных. А блобы - конечно не аналог файлов. Разве в них есть произвольный доступ?
Э-э-э, зачем суммы, зачем три копии? Проблема не в надежности физического диска, а в поддержании консистентного логического состояния на случай если все навернется посреди процесса. Чтоб после перезагрузки продолжилось с того же места. Ну, там файлы заружались-выгружались для отправки через сеть. С требованием чтобы они не терялись и не образовывались (т.е. отлавливались и выбрасывались) дубликаты. Оно там через флажки делалось. Ну и естественно содержимое файлов не вытаскивалось из базы один к одному, а собиралось запросом. Или в обратную сторону - наоборот разбиралось.
Вот оно может и не умное, а вроде вы до сих пор не поняли
Вся наша жизнь как цепь, а мелочи в ней звенья. Нельзя пренебрегать звеном.
А что, в файлы появился произвольный доступ ? давно ?
зачем суммы и зачем три копии ? чтобы если всё навернётся посреди процесса они не сошлись (или отсутствовали), и следовательно всё началось бы “с того же места”. И что тут непонятного
@Mikhail а я думал оно в беседку уедет
После сборки MD5 подсчитывается и ура. А флажки то зачем? Программирование на флажках это зло 
Ну так я существо медленное и непонятливое, большей части происходящего во круг не понимаю, пока не разберу по винтикам, а по винтикам разбирать не начинаю, пока не уверен, что соберу обратно
Именно сейчас не припоминаю про FireBird, но в Оракле в OCI есть произвольный доступ к BLOB/CLOB.
Sync в Оракле делается при определенных параметрах монтирования ФС и опции в самом Оракле.
А чем Вам журналируемые файловые системы не угодили???
Все великие шпионы валились именно на мелочах. 
А если же говорить о работе… “Подумаешь мелочи, переменную написал с орфографической ошибкой и компания потеряла несколько миллионов”. “Подумаешь, менеджер написал годовой отчет на корявом английском с кучей орфографических ошибок, и теперь с компанией никто не хочет иметь дело”. Ой, какие мелочи… Главное, что у него пальцы веером…
Хоть резюме своим форматированием и режет глаз, я полностью согласен с автором, что графа Objective не нужна, особенно, если резюме засылается на конкретную позицию через конкретного рекрутера.
Графа Objective может быть нужна в случае, когда резюме отправляется неизвестно кому, и неизвестно кто будет его читать. Но это, в любом случае, не оптимальный вариант.
Я тут далеко выхожу за рамки своей специализации, но мне всегда казалось, что у Оракла не BLOB а LOB (который на самом деле банальная ссылка на файл) а с самим файлом дальше можно делать всё то же, что и со всеми остальными файлами в мире … а к файлам на подавляющем большинстве ОС настоящего “произвольного” доступа - нет
в целом - затея эмулировать файловую систему средствами БД которая уже пользуется файловой системой, должна была быть расстреляна на стадии оценки необходимости проекта, и то, что она расстреляна не была говорит (лично мне) очень много нехорошего.
второй раунд вопросов был безнадёжно испорчен так и не начавшись
А что тогда делает фунция SetFilePointer() ? Перечитывает весь файл с начала?
от реализации зависит, но в лучшем случае - с начала последнего блока, так-что “тру” произвольности не видать
Предложение для домашнего чтения:
http://social.msdn.microsoft.com/Forums/en/windowssdk/thread/74df6c40-5416-4073-8b2e-11471b4c857e
Objective в первую очередь нужно написать для самого себя, чтобы потом резюме под это построить. Если резюме пишется как анкета, а не под конкретную позицию, то это резюме в стиле помойка или разруха, если это более точно передает смысл. И разруха, как Вы только что видели выше, начинается с головы автора.
Objective, в том виде в каком построено резюме sab123 (он на дайсе стразу три должности туда забил: содер, лид, менеджер) его полностью лажает с мечтами о менеджерской работе именно потому, что его резюме не написано как резюме менеджера или лида.
Резюме либо есть, либо его нет, независимо от канала рассылки или где его вывесят на поисковом сайте. Либо Вы можете ответить на вопрос какую работу ищете, либо нет. Либо рекрутер видет в Вас профессионала, либо еще кого-то, кто ищет “any job”. Вы только что слышали и видели, что резюме без Objective пишут люди, которые ПРИНЦИПИАЛЬНО не считают нужным вычищать в нем орфографию. И считают идиотами тех, кто на это обращает внимание. Вы, конечно, тоже можете пойти этим путем - это Ваш выбор. В этом случае нужно в резюме сознательно сделать десяток орфографических ошибок чтобы Вас не беспокоили идиоты, для которых это о чем-то говорит.
+1 заранее очень благодарен тем, кто их делает (меньше работы )
Мы об одном и том же говорим, просто я считаю, что писать Objective в буквальном смысле, т.е. как отдельную строчку в резюме - не имеет смысла, если вы заранее продумали своё резюме для конкретной позиции. Резюме может быть много - заточенные под определённую должность, страну, работодателя. У каждой версии свой objective, и читая хорошо составленное резюме можно понять, с какой целью оно составлено.
А то, что бесцельно написанное резюме канет в воду, с этим не имеет смысла спорить.
hamrah, Вам говорят о том, что резюме без Objective имеет меньше шансов быть прочитанным, а значит по определению хуже, чем резюме с Objective. Целью HR не является “прочитать все пришедшие резюме”, его целью является отобрать из xxx килограмм пришедших резюме нцать наиболее_подходящих для имеющихся позиций (угадать которые заранее Вы не можете принципиально).
А зачем работодателю (или рекрутеру) догадываться, что вы имели в виду? Он может бросить лишь один взгляд на резюме и понять, что с этим резюме дальше делать, а может, не читая и не напрягась в догадках просто выкинуть.
Это все равно что писать деловые письма, оставляя пустой графу “Тема”. Для меня это часть бизнес-этики.
Крутым пацанам резюме вообще не нужно. Видимо, в этом и непонимание между сторонами.
В более раннем изложении (Сирил Паркинсон. Законы Паркинсона)
Какой же метод применять нам в будущем? Чтобы его найти, рассмотрим
один малоизвестный вид современной техники отбора. Переводчиков-китаистов
для министерства иностранных дел приходится искать так редко, что метод их
найма не получил широкой огласки. Предположим, понадобился переводчик и
отбирает его комиссия из пяти человек. Трое из них - чиновники, двое -
крупные ученые. На столе перед ними лежат горой 483 заявления с
рекомендациями. Все соискатели - китайцы, все как один окончили
университет в Пекине или Амое и совершенствовались по философии в
американских университетах. Большинство из них служило какое-то время на
Формозе. Некоторые приложили фотографии, другие осмотрительно
воздержались. Председатель комиссии обращается к тому из ученых, который
покрупнее: “Не скажет ли нам доктор Ву, какой соискатель наиболее пригоден
для нас?” Д-р Ву загадочно улыбается и говорит, указывая на гору бумаг:
“Ни один”. - “Как же так, - удивляется председатель. - Почему?” - “Потому
что хороший специалист заявления не подаст. Побоится позора”. - “Что же
нам делать?” - спросит председатель. - “Я думаю, - ответит д-р Ву, - надо
уговорить доктора Лима. Как по вашему, доктор Ли?” - “Да, - отвечает Ли, -
он подошел бы. Но мы, конечно, не можем его сами просить. Мы спросим
доктора Тана, не считает ли он, что доктор Лим согласится”. - “Я не знаю
доктора Тана, - говорит Ву, - но я знаком с его другом, доктором Воном”. К
этой минуте председатель уже не понимает, кто кого будет просить. Но суть
тут в том, что все заявления выбрасывают в корзину, а речь пойдет лишь о
человеке, который заявления не подавал.