Как стать автором
Обновить

Комментарии 22

Разве что только тесты производительности :)
А, простите, смысл подобного *финта*?
А представь поиск по расшаренным ресурсам сети, состоящей из 100 компьютеров с такой файловой системой. Не стоит и говорить, что запукать стандартный поиск в таких обстоятельствах не имеет смысла... Я бы не стал ждать 5 минут в поиске фильма. А вот MySQL позволит это сделать за доли секунды. В этом и есть достоинство.
и каждый файл имеет свой уникальный идентификатор, по которому его ищут:-)
Нормальный проект, при условии использования для определенного набора задач.
Запись в базы данных (да и еще и содержимого никак под это не оптимизированного) действительно медленный процесс.
Но вот поиск выполнять проще и быстрее. Структуру можно сделать гораздо более гибкую.

PS
Да, кстати, и WinFS вроде еще грозит появиться.
> Но вот поиск выполнять проще и быстрее.
С чего бы это вдруг? Метаданных нет, данные в blob, поисковый индекс по "файлам" не создается.
Я надеюсь это не конечный вариант, а лишь технодемка. Имеется ввиду вообще использование базы данных вместо файловой системы.
На практике скорее всего придется создать смесь БД и ФС для обеспечения относительной производительности.
и получится Oracle, который по этой дорожке пошёл много лет назад. =)
Вот такое-вот нецелевое использование MySQL...
А потом теги на каждый файл, категории и будет социальная сеть ФС =)
reiserfs + соответствующий модуль написать, если еще нет
fs на базе бд обещают уже лет 10ть ... сейчас ms в своих коллективных софтинах всё файло в базы засовывает и похоже совсем скоро это будет везде
хранить файлы в базе данных, которые хранит эти файлы в файлах - что за бред..
Надстройка над надстройкой. :-)
которая повторяет функции прошлой надстройки =/
Бредом было бы хранить в базе образ реальной произвольной ФС, разбитой на кусочки и разложенной по blob'ам :)
если работать это будет быстрее, как показано на примере копирования исходников, то вполне себе вариант
У оракла есть RAW DEVICE... То есть не надстройка над ФС уже, к нему есть смысл наверно такое прикручивать
Ну вот собственно и ответ в плане производительности.
Это по серьёзней будет чем "теги" у Vistы.
Да и вообще раздолье в плане манипуляций _данными_.
Ох и кажется мне, что у этой идеи нет будущего. Да, 44Мб за 22 сек. это хорошо. Но проблема в том, что файлов обычно далеко не 44мб, а как минимум 44Гб, а сейчас уже и 440Гб.
Вам приходилось работать с такими таблицами? Из личного опыта - MySQL начинает очень тормозить при таблицах размером больше 4-5Гб.
Засунул в таблицу десяток фильмов - обратно не достанешь :)
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории