И не надо забивать себе голову решением задач, которые там уже давно реализованы. Sqlite ведь не требует сервера, это просто библиотека для работы с бинарными файлами с интерфейсом, поддерживающим привычные sql-запросы.
Случайно возникла такая мысль: виртуальная ФС, концептуально аналогичная VLAN. Т.е. файлы разным пользователям видны в совершенно разных каталогах по их усмотрению. Не точки монтирования, а, вообще - файлы одни и те же, а структуры каталогов и их размещение в них произвольно-различные.
Есть такое? Если нет - прошу считать данный пост первопубликацией данной идеи.
Вообще, большинство современных файловых систем поддерживают...02.10.19 19:38 Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 02.10.19 19:40 Количество правок: 1
Вообще, большинство современных файловых систем поддерживают жёсткие ссылки - одно тело файла, много имен файла в разных каталогах. Во вторых, есть файловые системы с дедупликацией страниц, например ZFS, но только на Linux.
не встречал07.09.19 13:10 Автор: dl <Dmitry Leonov>
Человек - существо разумное весьма условно. Потому, в тэгах всегда бардак, а осваивать поиск всем лень, как и тэги править. Даже - мне. А вот, ФС и браузер - вещи, которые все поневоле знают и пользуют.
ну вот практика показала, что обычным людям проще искать, чем раскладывать по иерархиям10.09.19 01:42 Автор: dl <Dmitry Leonov>
Прежде всего - откуда это все вылезло:
Счас ковыряюсь в Ведроиде - пытаюсь написать свой аудиоплейер. А почему? Потому, что все пытаются юзать андроидовскую систему медиабиблиотек с сортировкой по авторам, альбомам и т.д. Все это не работает и никогда работать не будет и, потму, аццки мешает. Потому, что человек не робот и никогда не будет заполнять тэги медиафайлов и, уж точно, никогда не будет это делать правильно и единообразно. А еще, он будет пихать туда спам и вирусню. Все это в результате вместо порядка только ухудшает бардак.
В то же время, файловая система - идеальное упорядоченное хранилище, которым все умеют и, полюбас, вынуждены пользоваться. Скачивая файлы, ты, неизбежно, куда-то как-то их распихиваешь, упорядочивая по своему усмотрению. Чего еще-то надо?!
Сначала я хотел оставить в плейере только файл-браузер и сделать текущую очередь треков, в которую файлы бы перетаскивались из окна браузера пальцем и там же пальцем перемещались вверх-вниз. Эта же очередь, нажатием кнопки, сохранялась бы, как плейлист. И тут сразу вопрос: "Куда и под каким именем? Как я буду это потом искать и понимать?"
Вот, тогда и возникла мысль о виртуальных многосвязных ФС. Допустим, у меня в папке Медиа будут папки "Файлы", "Авторы", "Альбомы", "Плейлисты"... в которых содержатся линки на одни и те же файлы из папки "Файлы", но - в разных, по моему усмотрению, подпапках и с разными, по моему усмотрению, именами и датами создания в порядке проигрывания. Все это должно обрабатываться не с помощью каких-то опций плейера или других утилит, которые еше надо изучить, а с помощью любого файл-браузера.
Конечно, Ведроид для этого плохо приспособлен, поскольку у него нет стандартного Експлорера и стандартных диалогов открытия/сохранения файлов, но вот в виндах-линуксоидах это должно получиться удобно. Главное, чтобы линки не приходилось создавать вручную - это, опять, никто делать не будет, а джелала бы это сама система/плюгин в ней. Скажем, создал виртуальный диск/каталог и - все, реальный перенос файлов туда с реального диска запрещен, а "видимый" перенос/копирование будут создавать только линк, в то же время, внутри виртпапки линки можно стирать/переносить/копировать, но реального файла там быть не может.
Описание напоминает реализацию графа в БД.02.10.19 19:45 Автор: Den <Денис Т.> Статус: The Elderman
По мере увеличения памяти компьютеров необходимость в специальном софте для хранения и администрирования большого количества таблиц на диске снижается, а ООП "отрывает" у СУБД огромный кус в упроавленческом софте. Вместо таблицы - объект "склад" с полями-объектами "стеллаж", всключающими объекты - "полки", объекты - "ящики", объекты - "детали"...
Не обязательно использовать ORM! Можно использовать...12.10.19 20:47 Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 12.10.19 20:48 Количество правок: 1
> По мере увеличения памяти компьютеров необходимость в > специальном софте для хранения и администрирования большого > количества таблиц на диске снижается, а ООП "отрывает" у > СУБД огромный кус в упроавленческом софте. Вместо таблицы - > объект "склад" с полями-объектами "стеллаж", всключающими > объекты - "полки", объекты - "ящики", объекты - "детали"...
Не обязательно использовать ORM! Можно использовать классическую 3NF по сущностям данных, а не типам, и классический нативный клиент с SQL запросами.
причем для всего этого активно используют sqlite...14.10.19 00:36 Автор: dl <Dmitry Leonov> Отредактировано 14.10.19 00:39 Количество правок: 2
Интегрировали в Ведро БД и тепер каждый идиот пихает его во все дыры. Ну, объясните полудурку, нахрена БД, скажем, в аудиоплейере?!
Чтобы создать тот самый граф, который тебе нужен! :)21.10.19 22:37 Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 21.10.19 22:47 Количество правок: 3
Ты можешь в БД хранить и вертеть интересующие тебя данные хоть в "фас", хоть в "профыль", хоть кубы аналитики строить, при том, что файлы треков как лежали размазанными по разным папкам, так и будут лежать. Строишь справочную таблицу ссылок на файлы с первичным синтетическим ключом, выдёргиваешь из треков нужную тебе информацию, формируя таблицы сущностей и строя графы зависимостей с привязкой на упомянутую справочную таблицу и вертишь этими данными в выборке как тебе надо.
А вообще, можно даже сами аудиофайлы засунуть в БД в виде BLOb'ов и не будет никакой файловой помойки. Плюс ко всему, можно самостоятельно организовать дедупликацию, создавая для каждого BLOb'а хэш SHA-256, ASIC поддержка которого есть практически во всех современных процах, дополненный сравнением содержимого при совпадении хэша, в т.ч. и в ARM.
Могу. А так же - стрелять из пушки по воробьям и забивать микроскопом гвозди.27.10.19 05:18 Автор: Zef <Alloo Zef> Статус: Elderman
Данный пример применим и к файловым системам, как СУБД. Данные находятся по фигу где - в разных секторах. Пользовательскому софту и, в конце концов, человеку это не видно.24.10.19 12:43 Автор: kstati <Евгений Борисов> Статус: Elderman Отредактировано 24.10.19 12:43 Количество правок: 1
И не надо забивать себе голову решением задач, которые там уже давно реализованы. Sqlite ведь не требует сервера, это просто библиотека для работы с бинарными файлами с интерфейсом, поддерживающим привычные sql-запросы.
SQL СУБД embedded "из коробки".21.10.19 22:38 Автор: Den <Денис Т.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
