Имеем файловую базу данных, где сама база представляет собой один файл, например:

1С 8, MS Access.

Везде при подключении пользователя к базе создается доп. файлик, в котором пишется, что пользователь подключился. В Акцесс, например, там пишутся имя пользователя и компьютер. Когда последний пользователь отключится, этот файлик обычно удаляется.

Вопрос: Зачем так сделано. Можно было этот "файлик" запихать в виде таблицы в саму базу, почему так не делают?

Чем навеян вопрос: Если бы все писалось в саму базу, то можно было бы расшарить папку с базой на сервере и убрать права удаления, добавления файлов ...

ах, да.

как думаешь, насколько быстрее обратиться к файлу в несколько десятков килобайт и к файлу в несколько десятков гигабайт?

(0) в поиск по имени файлика - найдешь много интересного

и да

(2) А зачем туда обращаться? Этот файл читается/записывается в двух случаях вход и выход ... В базе же все равно будешь работать и читать эти гигабайты

(5) поставь эксперимент и не создавай тупые ветки.

(6) Хорошо, пусть этот файл читают и во время работы с базой, допустим.

Но с базой-то все-равно работаешь и файл с ней читаешь, вот ни пофиг ли еще одну табличку почитать

(0) ни с файловой 1С, ни с mdb работать нельзя, это атавизм

нужно ограничение доступа - используй сиквел

(0) Все просто, при запуске система определяет заблокирован ли он, если нет и существует, то происходило аварийное завершение работы.

Да пофигу. Файловые базы не для скорости и масштабируемости делаются, а от безысходности. В этом смысле пофигу, как там блокировки реализованы

(10) Да фиг с ней, со скоростью, благодаря отдельному файлу блокировок нет возможности защитить файл от удаления особо отчаяными пользователями

(2) Монопенисуально, если знаешь смещение.

(12) "какьийе ващьи доказьательсьтвьа"? (с)

(11) а ты хочешь, чтобы они всю базу удаляли?

(13) а ваши? :)

если следовать этой логике, терабайтные скулевские базы не должны существовать в природе

(11) что мешает защитить файл базы от удаления?

(15) во блин, ну ты же вменяемый, что быстрее - считать файл целиком в 20кб или спозиционироваться на 500-гиговом файле? причем чтоб спозиционироваться, надо сначала в нем же найти куда указатель перемещать.

(17) Искать нечего не надо, там наверняка фиксированная структура, точнее тебе скажут создатели ToolCD всяких и статьи на Инфостарте.

(18) нифига там не фиксированная структура. там аналог ФАТ. и если по базе охрененная фрагментация то ты упаришься ждать.

(19) один раз ФАТ в память загрузил, и читать её не надо, только писать

(16) Как? Удаление файлов - разрешается/запрещается для папки, содержащей файл, поэтому запретить удаление невозможно.

(20) В случае с файловой системой ты прав - там пользователь, по-сути, один - сама ОС, все чтения/записи идут через нее, и поэтому ОС может всегда иметь актуальный кэш FAT.
В случае многопользовательской работы с файловой БД это не совсем так. Кэш, конечно, использовать надо, но при этом надо каждый раз проверять, что кэш актуален, чтобы убедиться, что другой пользователь не изменил только что что-нибудь в FAT. Делается это с помощью версионирования. Но это, в свою очередь, тоже означает доп. расходы - как при записи, так как кроме записи собственно данных, надо записать и новую версию объекта, так и при чтении, прежде чем использовать кэшированные данные, надо все равно прочитать версию объекта из базы, чтобы определить актуальность кэша.

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

(20) А для файлов что, удаление не разрешается/запрещается?

Чтобы можно было снять зависшую блокировку простым удалением файла.