Сразу приношу извинения - я не программист, поэтому, буду очень признательна за «доступные» ответы.

Мы - маленькое кадровое агентство. У нас довольно приличная база резюме - уже больше 700 000. До настоящего времени мы пользовались Access – в базе буквально 3 поля:
1. МЕМО – индексированное, совпадения не допускаются (все резюме полностью вкладывается в это поле). 2. дата, время (по умолчанию now). 3. и поле счетчик
Дополнительно есть несколько запросов, которые позволяют делать выборки по базе: по дате размещения и по конкреному слову. Запросы копируют данные из основной в новые таблицы с которыми потом сотрудники и работают.

Эту базку много лет назад делала сама, поэтому в ней все просто до неприличия. Но, естественно, при таком объеме информации скорость выборок очень медленная да и «глючить» база начала (может тоже из-за объема информации?).

Некоторое время назад мы стали подумывать о том, чтобы сделать новую базу – может быть на чем – то другом. Пробовали общаться с программистами, но их ответы не вызывают доверия. Кто-то убеждает, что у нас самый идеальный вариант (хотя это явно не так), кто – то пытается нас «раскрутить» на полугодовой проект с бюджетом в 10-15 тысяч долларов. Такая разница нас, некоторым образом, смущает.

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

Подскажите пожалуйста, на что лучше поменять access а нашем случае. В простом варианте, чтобы база работала для одного пользователя, в идеальном – для 7-8?

Я честно прочитала все сообщения форума о смене access на другие базы, но не могу определиться. Ибо мой разум некоторых вещей просто не понимает.
Буду признательна за доступные объяснения, которые помогут мне найти общий язык с программистами при выборе замены access.

Спасибо.

OS/360 Ggg_oldА ведь верно. Lotus Notes для однопользовательсной системы и Lotus Domino для многопользовательской отлично подойдет. Причем даже особенно ничего писать не надо, подойдет одна из поставляемых с лотусом БД типа Document Library. Стоит копейки. Единственный минус, - лотусятный программер недешево стоит, и прйдется ему повозиться с переносом документов в новую БД. И желательно все-же сразу брать Домино и работать с БД через веб, т.к 700тыс документов реплицировать и хранить на локальный Lotus Notes как-то ене очень правильно.

^{все наши на www.corba.kubsu.ru}

полнофункциональные "демо" доступны на www.lotus.com

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

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

Искренняя благодарность от глупого начальства.

Спасибо всем и Flare в частности.
Всем за то, что наставили на путь истиный, а Flare за то, что увидел действительное положение вещей и показал наиболее оптимальный выход на данный момент. Наверное так и сделаем - по "авралу" - MS SQL с Access, и на дальнейшее посерьезнее базку начнем потихоньку выстраивать.

Честно говоря, обращаясь на форум, я не ожидала получить реальную помощь. Еще раз спасибо.

И личное сообщение для blueomega (не не могу удержаться :) )- а кто сказал, что у нас "проблемы"? У нас локальная неприятность с базой резюме, которая, как оказалось, достаточно быстро решается. Если хотите узнать, что такое проблемы - сообщие - вышлю списком :) Хотя, тоже спасибки за дистанционную оценку нашей работы. Надеюсь, вы не допускаете ошибок в жизни.

Андрей Леонидович!
Безусловно Вы правы. И это именно "обида" - потому что приходится научиться разбираться в "основах" очень многих вещей - начиная от соц пакета для сотрудников и заканчивая БД и налогами и "всеми прочими моментами", ибо без этого даже поставить задачу исполнителю невозможно. Поэтому, действительно обидно слышать упреки в некомпетентности, от людей, занимающихся каким-либо одним направлением. Я здесь именно потому, что хочу сориенироваться как "лучше" будет для дальнейшей жизни.
И эта "заморочка" с базой перекрыла нам доступ к резюме. И, безусловно, я не воспринимаю это как мелкую неурядицу. И я понимаю, что "дальше так нельзя". :) Поэтому ищем пути.

100 таблиц?? я уже думала, что таблиц будет много. но - 100??? Значит нужно подумать еще. Попробую :)

Мальчики, мужчины, господа, товарищи!! (женщин, как мне кажется, здесь не было).

У меня праздник!

Я только что справилась с ошибкой нашей дурацкой базы и теперь смогу выудить из нее все то, к чему она меня не допускала две недели!!

Траур окончен - сегодня просто праздник!!

А с завтрашнего дня с холодной головой начну размышлять над всеми Вашими предложениями.
ЧМОКИ! ВСЕХ ЛЮБЛЮ.

Индекс в МЕМО - чтобы избежать вложения идентичных резюме. Поскольку резюме часто присылают по нескольку раз. И сотрудник, занимающийся "разборкой" просто не в состоянии все запомнить. Безусловно, если кандидат вносит изменения в резюме, то этот индекс становится бесполезным. Но в целом позволяет уменьшить объем базы процентов на 10-30 в зависимости от источника резюме.

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

В начале работы мы пробовали заводить все резюме "вручную", оставляя индексным полем поле ФИО (но, если бы вы знали сколько встречается людей с одинаковыми именами) и по номеру телефона - то же самое - как только попадаются резюме "одной семьи" - возникают проблемы. Остается по эл. почте, наверное, но тут уже наш энтузиазм закончился и мы сделали по всему полю целиком.

"а вы не пробовали сами резюме держать в файлах на диске а в базе данных ссылки на файл плюс какую-то доп. информацию для поиска. Формат файлов может быть текстовой или rtf."

- не пробовали. Потому что в такой форме можно держать резюме кандидатов УЖЕ БЫВШИХ на собеседовании - что мы и делаем. Таких резюме не слишком много и мы вполне можем их обработать вручную.

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

"И сам ответ по поводу замены Access для хранения резюме. ИМХО оптимальный путь такой: Access => Access с разделением большой таблицы по файлам mdb => Access + MSDE."

- в принципе мы уже начали делить старую базу и разносить по разным таблицам - пока в Access. За основу взяли рубрикатор www.rabota.ru (немного изменили, конечно). На большее у нас пока времени не хватило. Пока ее разбиваем на части - поточнее продумаем схему.

КСТАТИ - вариант Erik - у нас народ пользуется программой Яндекса, только она, кажется, по сети не ищет. Спасибо. Посмотрим 'Google desktop 2.0'