Создание богатой структуры данных в традиционной реляционной базе данных, такой как MySQL, часто может быть трудным, и есть гораздо лучшие способы сделать это. При работе со структурой данных на основе пути с иерархией мне нравится создавать систему на основе плоских файлов, которая использует формат сериализации данных, такой как JSON, для хранения информации о конкретном файле, каталоге или целом хранилище.
Таким образом, вы можете использовать текущие доступные инструменты для удобной навигации и управления структурой, а также легко читать, редактировать и понимать структуру. XML тоже хорош для этого - он немного более многословен, чем JSON, но легко читается и хорош для обмена сообщениями и других систем на основе XML.
Быстрый пример. Если у нас есть хранилище, в котором есть каталог и три файла. Глядя на него спереди, он будет выглядеть так:
/repo
/folder
code.php
file.txt
image.jpg
У нас может быть папка метаданных, которая содержит наши файлы JSON, скрытые от ОС, в корне каждого каталога, которые описывают содержимое этого каталога. Так работают традиционные системы управления версиями, за исключением того, что они используют собственный язык вместо JSON.
/repo
*/.folderdata*
/code
*/.folderdata*
code.php
file.txt
image.jpg
Каждая папка .folderdata может содержать свою собственную структуру, которую мы можем использовать для правильной организации данных папки. Каждая папка .folderdata может быть сжата для экономии места на диске. Если мы посмотрим на папку .folderdata внутри каталога / code:
*/.folderdata*
/revisions
code.php.r1
code.php.r2
code.php.r3
folderstructure.json
filerevisions.json
Структура папок определяет структуру нашей папки, где файлы и папки связаны друг с другом и т. Д. Это может выглядеть примерно так:
{
'.': 'code',
'..': 'repo',
'code.php': {
'author_id': 11543,
'author_name': 'Jamie Rumbelow',
'file_hash': 'a26hb3vpq22'
'access': 'public'
}
}
Это позволяет нам связывать метаданные об этом файле, проверять подлинность и целостность, сохранять постоянные данные, задавать атрибуты файла и делать многое другое. Затем мы можем сохранить информацию о конкретных ревизиях в файле filerevisions.json:
{
'code.php': [
1: {
'commit': 'ah32mncnj654oidfd',
'commit_author_id': 11543,
'commit_author_name': 'Jamie Rumbelow',
'commit_message': 'Made some changes to code.php',
'additions': 2,
'subtractions': 4
},
2: {
'commit': 'ljk4klj34khn5nkk5',
'commit_author_id': 18676,
'commit_author_name': 'Jo Johnson',
'commit_message': 'Fixed Jamie\'s bad code!',
'additions': 2,
'subtractions': 0
},
3: {
'commit': '77sdnjhhh4ife943r',
'commit_author_id': 11543,
'commit_author_name': 'Jamie Rumbelow',
'commit_message': 'Whoah, showstopper found and fixed',
'additions': 8,
'subtractions': 5
},
]
}
Это базовый план системы управления версиями файлов - мне нравится эта идея и то, как она работает, и в прошлом я использовал JSON, чтобы добиться большого эффекта с такими богатыми структурами данных. Такого рода данные просто не подходят для реляционной базы данных, такой как MySQL - по мере того, как вы будете получать все больше ревизий и больше файлов, база данных будет становиться все больше и больше, таким образом вы сможете разбивать ревизии по нескольким файлам, хранить резервные копии всего, уверен, что у вас есть постоянные данные через интерфейсы и платформы и т. д.
Надеюсь, это дало вам некоторое представление, и, надеюсь, оно даст пищу для размышлений и сообществу!