guest_20040621> он так и написал )))

Читать нужно то, что написано, а не между строк.
А там именно это и написано, в самих строках ))))

guest_20040621
>А кому придет в голову руками менять имена файлов, можете сказать?

Мало ли, нельзя ручаться за то, что от нас не зависит.

guest_20040621
> А теперь посчитайте стоимость файлового сервера такого же объема и сравните со стоимостью
> железки, которая будет обслуживать эту базу данных (плюс стоимость резервного копирования
> и восстановления).

Зачем считать, достаточно прикинуть что для БД в 10 терабайт, плюс минус несколько гигов накладных расходов - это копейки

guest_20040621
>Уважаемый дон представляет себе стоимость отказоустойчивых решений?
>Или языком потрепать пришел?

Это же развод на флуд )))

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

И это тоже

guest_20040621
Дружище, Вы никогда не видели баз данных размером в десять терабайт, никогда не делали их бэкап и не восстанавливали их. ОК, оставайтесь самоделкиным.

Есть существенная разница: бэкапить 10 ТБайт или 10,3 Тб? Объясните дружище?


guest_20040621
Для продолжающих тупить: стоимость решений будет различаться на порядок в лучшем случае.

Ага, че не на два :))

guest_20040621> Установили флаг, удалили файл, убедились, что его нет, установили второй флаг, увидели два флага, пометили данные удаленными. Где проблемы?

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

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

Может это будет для вас откровением, но современные СУБД могут работать в распределенном режиме,
и выполнять распределенные (опять же) транзакции, с уже заложенным механизмом обеспечения целостности.

guest_20040621> Это надо реализовывать, или оно само сделается?

На все идиотские вопросы нужно отвечать?

Кто вас научил отвечать вопросом на вопрос?

guest_20040621
Какой транзакции, уважаемый? Если файл не был удален, ничего страшного для базы данных не произошло.

Коллега, мне право стыдно объяснять вам, что такое откат транзакции.
почитайте на досуге хоть это http://ru.wikipedia.org/wiki/Rollback

guest_20040621
Видимо, это для Вас откровение, сколько времени занимает бэкап и восстановление базы данных размером 10 Тб.

Дружище, 10 Тб они и в Африке 10 Тб

guest_20040621
> но современные СУБД могут работать в распределенном режиме
А бэкапиться частями они тоже уже научились?
При желании можно

guest_20040621> Похоже, я плохо объяснил. Для пользователя файл будет обладать ровно теми же атрибутами доступа, что и любая другая сущность базы данных. Просто потому, что никто никакого другого интерфейса ему не даст. Для приложения количество файловых серверов не ограничено. Для каждого из файловых серверов есть аккаунты, под которыми и происходят изменения их содержимого. Об этих аккаунтах пользователь ничего не знает, у него есть доступ только к приложению.
А где хранятся акаунты?
Жестко зашиты в приложение?

Я так понимаю, после запуска приложение само логинится на FS?
После этого что помешает юзеру зайти на сервер через сетевое окружение?