хранение ext3 в базе данных sql - PullRequest
Новая
       43

хранение ext3 в базе данных sql

0 голосов
/ 17 ноября 2018

Можно ли хранить систему типа ext3 в mysql?Например, чтобы построить систему метаданных файлов, которая будет включать пути и разрешения?Если да, то каков пример этого формата?Я предполагаю, что начальный денормализованный маршрут будет здесь: 

-rw-r--r--@  1 david  staff   552B Nov  2 15:55 wsgi.py
-rw-r--r--   1 david  staff   113B Oct 30 20:45 ~.bash_profile

Таким образом, у нас будет 7 столбцов: 

permissions | links | user | group | size | date | filename

Полагаю, нам понадобятся еще два столбца для «управления»: 

fileId | directoryId

Кажется ли это далеко от базы, или это было бы возможно?Что было бы лучшим и более нормализованным способом сохранить это?

1 Ответ

0 голосов
/ 17 ноября 2018

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

Я бы имел (как минимум) 2 таблицы: Files и Directories. Файл будет иметь dir_id. Каталог будет иметь как dir_id для себя, так и parent_id для перехода по дереву каталогов. Верх дерева («корень») будет нулем или нулем.

Мягкие ссылки, жесткие ссылки, устройства, монтирования, / proc и т. Д. Добавят проблем, но, может быть, вас это не волнует?

size должно быть BIGINT. permissions, если закодировано, может вписаться в SMALLINT UNSIGNED или может быть сохранено как строка. user и group могут быть либо идентификатором, либо строкой; вам может понадобиться таблица id: name для пользователей и одна для групп. Для date рассмотрим TIMESTAMP или, может быть DATETIME; имейте в виду, что ОС может делать что-то ближе к TIMESTAMP для работы с часовыми поясами. (Возможно, Windows отличается.)

Если вы храните копии файлов, я рекомендую использовать другую таблицу, связанную с Files через file_id. Но, будьте осторожны, LONGBLOB ограничен 4 ГБ, и есть другие настройки, которые затрудняют хранение чего-либо большего, чем 16 МБ. Итак, я мог бы предложить разбить на куски что-нибудь больше, чем 64 КБ, сжать куски и т. Д. (Для этого, вероятно, потребуется еще одна таблица.)

Что касается восстановления полного пути из "иерархии", которую я предложил выше, то это всего лишь небольшой объем кода. Это можно сделать в коде вашего приложения или в хранимой процедуре. В MySQL 8.0 или MariaDB 10.2 доступны «CTE» для облегчения детализации дерева.

(Да, я делал большинство этих вещей в нескольких проектах в прошлом.)

...