Re[8]: Почему дерево в основе? Файловая система, проекты... - Компьютерные священные войны

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Hоmunculus, Вы писали:

H>>Потому что наше сознание иерархично. И само бытие иерархично. Как бы всякие анонимусы2 ни пытались все замешать в серую однородную каловую массу

S>Тогда почему люди не хотят признать что многоуровневое наследование (тоже дерево) — наше все?

Ну у него спроси. Дерево отражает реальный мир. Потому даже во многих мифах — дерево в основе мироздания.
Электроны-атомы-молекулы-организмы — даже это — дерево

Здравствуйте, Hоmunculus, Вы писали:

H>Ну у него спроси. Дерево отражает реальный мир. Потому даже во многих мифах — дерево в основе мироздания.

Ну вот генеалогическое дерево — вроде дерево, а родителей то двое... Притом иногда бывают инцесты, т.е. петли как бы (пример Лота).

H>Электроны-атомы-молекулы-организмы — даже это — дерево

Но это тоже концептуально, как бы если выделить отдельные сущности, абстракции.

Здравствуйте, Shmj, Вы писали:

S>Ну вот генеалогическое дерево

Потому что генеалогическое дерево — это дерево фамилии. И это реально дерево.

Здравствуйте, Shmj, Вы писали:

S>Тогда почему люди не хотят признать что многоуровневое наследование (тоже дерево) — наше все?
Потому что у тебя жесткие пролемы с пониманием. Если ьы не видишь разнцы между "мне приятны деревья" и "деревья хорошо работают" то

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
S>Вроде есть не древовидные файловые системы, но особо не получили признания.

Потому что это минимум из того, что реально работает под реальные запросы.
А реальные запросы -- это, например, когда у тебя есть чего-то (не важно, программа, книга из нескольких глав), и у тебя в одном каталоге одна версия, а в другом другая. Ты берёшь сущность в каталоге и делаешь полное копирование через копирование каталога.

Если не это, то плоская структура с отдельными индексами -- как в библиотеке, когда одна и та же книга может быть одновременно учебником математики, детской сказкой и написанной шведом. MS делала несколько попыток перевести на такую систему сами FS, не получилось.

А ещё есть симлинки, которые превращают дерево в направленный граф.

Неудачные попытки всё сделать только на контексте -- см. например Canon Cat.

S>Или вот даже проекты, файлы проекта. Важно отнести файл к конкретному пространству иерархии. А что если он и туда и сюда? Если бы не дерево — то можно было бы добавить его в два места одновременно, но так не принято — только один вариант нужно выбрать.

Симлинк поставь. Есть места, где так и делают.

Вообще было бы интересно посмотреть на IDE по тому же принципу, когда, например, в каталоге лежат только файлы вида abcd0123.cxx, а то, что это одновременно src/logic/ordering.cxx и src/util/collections/sorted_array.cxx, записано где-то в метаданных.
Но я сомневаюсь, что это бы выжило.

Здравствуйте, Shmj, Вы писали:

S>Ну вот генеалогическое дерево — вроде дерево, а родителей то двое... Притом иногда бывают инцесты, т.е. петли как бы (пример Лота).

Что-то я не помню, чтобы он был, например, сыном собственного внука

А иначе это не петля.

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
вначале были плоские, типа файловой системы в cp/m, директории появились после — как естественное развитие

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

А какая альтернатива?

Здравствуйте, Marty, Вы писали:

S>>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
M>А какая альтернатива?

Типа теги. Как в RSDN каждый пост только в одной ветке дерева. А на Хабре — можешь один пост добавлять в n хабов одновременно.

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

Потому что это гарантирует однократное вхождение элемента, в данном случае файла. В свою очередь путь к файлу тоже только один. А мозги у людей эволюционно созданы для перемещений в пространстве. Им так же проще помнить один путь к объекту нежели множество путей. Потому что множество путей это выбор для мозга, а один путь автопилот. Каждый раз выбирать это лишние мозговые усилия. То есть люди выбирают системы, которые тратят меньше мозговых усилий при их использовании.

Здравствуйте, Shmj, Вы писали:

S>>>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
M>>А какая альтернатива?

S>Типа теги. Как в RSDN каждый пост только в одной ветке дерева. А на Хабре — можешь один пост добавлять в n хабов одновременно.

Одноуровневая иерархия с использованием симлинков/хардлинков? Ну, такое себе. В некоторых применениях удобно, но именно что только в некоторых. В качестве универсальной системы это был бы ад

Здравствуйте, netch80, Вы писали:

S>>Или вот даже проекты, файлы проекта. Важно отнести файл к конкретному пространству иерархии. А что если он и туда и сюда? Если бы не дерево — то можно было бы добавить его в два места одновременно, но так не принято — только один вариант нужно выбрать.

N>Симлинк поставь. Есть места, где так и делают.

Или хардлинк. В отличие от симлинка, который по существу только ссылка, хардлинк — полноценное второе имя файла, лежащее в другом каталоге.

Здравствуйте, Pavel Dvorkin, Вы писали:

N>>Симлинк поставь. Есть места, где так и делают.

PD>Или хардлинк. В отличие от симлинка, который по существу только ссылка, хардлинк — полноценное второе имя файла, лежащее в другом каталоге.

Хз как в ваших линупсах, а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске. Симлинки такой хернёй не ограничены, но в винде, внезапно, по дефолту хардлинки делать можно на уровне пользователя без проблем, а симлинки требуют админских прав, или что-то там подкрутить в настройках системы. Кстати да, может мне кто-нибудь объяснит эту херню?

Здравствуйте, Marty, Вы писали:

PD>>Или хардлинк. В отличие от симлинка, который по существу только ссылка, хардлинк — полноценное второе имя файла, лежащее в другом каталоге.

M>Хз как в ваших линупсах,

Он совсем не мой.

>а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске.

Еще бы. Это еще одна запись в MFT, у которой тот же набор LCN-VCN. Никак это не может быть вне пределов логического диска.

>Симлинки такой хернёй не ограничены, но в винде, внезапно, по дефолту хардлинки делать можно на уровне пользователя без проблем, а симлинки требуют админских прав, или что-то там подкрутить в настройках системы. Кстати да, может мне кто-нибудь объяснит эту херню?

Как гипотеза, не более.

Если есть доступ к файлу, то сделать ему хардлинк — просто дать второе имя. Если в target каталоге есть право на создание файла, то угроз безопасности я не вижу. Можно любому разрешить.

А симлинк может вообще на сетевой диск показывать, и еще вопрос, что потом может быть, как там с правами будет потом и с самим наличием диска тоже. Ну и во избежание проблем решили дать только под ответственность админа.

Здравствуйте, Shmj, Вы писали:

S>Вроде есть не древовидные файловые системы, но особо не получили признания.

1. Банально legacy. Все эти ваши windows/linux/mac уже спроектированы под дерево. И любая недревовидная система должна быть лишь надстройкой.
2. Когда вы задаёте путь вы заставляете пользователя продумать и задать теги для дальнейшего поиска. А в тег-ориентированной системе вас никто не заставляет этого делать. В итоге файл ложится в общую кучу без всяких тегов вообще. Найти нереально, принять решение об удалении невозможно.

Здравствуйте, sergii.p, Вы писали:

SP>2. Когда вы задаёте путь вы заставляете пользователя продумать и задать теги для дальнейшего поиска. А в тег-ориентированной системе вас никто не заставляет этого делать. В итоге файл ложится в общую кучу без всяких тегов вообще. Найти нереально, принять решение об удалении невозможно.

Так можно ж сделать минимум один тег обязательным. А так же возможность тегам так же назначать теги.

S>Типа теги. Как в RSDN каждый пост только в одной ветке дерева. А на Хабре — можешь один пост добавлять в n хабов одновременно.
Ну так теги реализуются в любой современной фс — берешь свои файлы и складываешь в одну директорию под именами-тегами. Вуаля.
И да, несколько имен у одного файла поддерживают все современные ФС.

Здравствуйте, Shmj, Вы писали:

SP>>2. Когда вы задаёте путь вы заставляете пользователя продумать и задать теги для дальнейшего поиска. А в тег-ориентированной системе вас никто не заставляет этого делать. В итоге файл ложится в общую кучу без всяких тегов вообще. Найти нереально, принять решение об удалении невозможно.

S>Так можно ж сделать минимум один тег обязательным. А так же возможность тегам так же назначать теги.

И получается путь к файлу и симлинки/хардлинки на него

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

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

Здравствуйте, Marty, Вы писали:

M>Хз как в ваших линупсах, а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске.

В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
Если диск (флешка) отмонтированы, то ссылка указывает в пустоту (и показывается красным цветом).

M>>Хз как в ваших линупсах, а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске.
A>В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
хардлинки (ln без ключика -s) в линуксе тоже только в пределах одной файловой системы (точки монтирования) можно делать

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
S>Вроде есть не древовидные файловые системы, но особо не получили признания.
S>Или вот даже проекты, файлы проекта. Важно отнести файл к конкретному пространству иерархии. А что если он и туда и сюда? Если бы не дерево — то можно было бы добавить его в два места одновременно, но так не принято — только один вариант нужно выбрать.
Во-первых, фс — это не для нас, а для программ по большому счёту. Это довольно низкоуровневая штука. Для нас уже будут всякие хабры и рсдны как в твоих примерах ниже.
Во-вторых, фс отражает физический уровень. А там естественным образом получается дерево компонентов: компьютер -> типы девайсов (cd/hdd/net) -> девайс -> партиции.
В-третьих, элементарные операции с файлами. Система тегов работает только в вырожденном случае, когда всё однородно и централизованно. Как ты себе представляешь запись сразу в 5 мест? Одно из них таки сработает, другое — нет прав, третье — нет места, четвёртое — тормозит, а пятое вообще только для чтения.

Ну а проекты — обычно лежат в файловой системе. И дальше все тулзы с ними работающие. Как ты будешь диффить|мержить|патчить и т.п. если какая-то сложная система зависимостей всего от всего?..

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

Вдогонку: рывок популярности VSCode с самого начала. Голый редактор, редактирующий что угодно в пределах одного каталога, и расширения вокруг него.

Как раз следствие того, что удобно сгруппировать всё в одну сущность (назвать папкой, комнатой, карманом чёрта лысого) и возиться внутри неё.

Здравствуйте, alpha21264, Вы писали:

M>>Хз как в ваших линупсах, а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске.

A>В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
A>Если диск (флешка) отмонтированы, то ссылка указывает в пустоту (и показывается красным цветом).

хардлинк?

Здравствуйте, netch80, Вы писали:

N>Вдогонку: рывок популярности VSCode с самого начала. Голый редактор, редактирующий что угодно в пределах одного каталога, и расширения вокруг него.

N>Как раз следствие того, что удобно сгруппировать всё в одну сущность (назвать папкой, комнатой, карманом чёрта лысого) и возиться внутри неё.

Ну хз, VSCode использую от безысходности обычно, если есть возможность, использую MSVS

Здравствуйте, Shmj, Вы писали:

S>>>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
M>>А какая альтернатива?
S>Типа теги. Как в RSDN каждый пост только в одной ветке дерева. А на Хабре — можешь один пост добавлять в n хабов одновременно.

Простите, а комментарии на Хабре тоже не привязаны к дереву? Можно положить комментарий и тэгами разметить к каким другим постам и комментариям он относится?

Здравствуйте, Shmj, Вы писали:

S>Или вот даже проекты, файлы проекта. Важно отнести файл к конкретному пространству иерархии.

Наверное, потому что важно потом его найти и дерево — работает хорошо. Если найдется что-то что работает для данного вида работы лучше — на него быстро перейдут.

S>А что если он и туда и сюда? Если бы не дерево — то можно было бы добавить его в два места одновременно, но так не принято — только один вариант нужно выбрать.

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

S>Так можно ж сделать минимум один тег обязательным. А так же возможность тегам так же назначать теги.
Это ты сейчас придумал иерархичность.
Директории и имя файлов — можно считать такими иерархичными тегами, раз тебе концепция тегов нравится, а имя — обязательный тег.
А для любителей множества тегов на один файл — есть ссылки.

Здравствуйте, Marty, Вы писали:

A>>В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
A>>Если диск (флешка) отмонтированы, то ссылка указывает в пустоту (и показывается красным цветом).

M>хардлинк?

Говорят, что в пределах диска.
А вообще, какая разница?
Не, я знаю, что реализовано по-разному, но с точки зрения пользователя разница какая?

Здравствуйте, alpha21264, Вы писали:

A>>>В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
A>>>Если диск (флешка) отмонтированы, то ссылка указывает в пустоту (и показывается красным цветом).

M>>хардлинк?

A>Говорят, что в пределах диска.

Не врут? Хардлинк — это же просто запись в каталоге и инкремент inode, разве это может быть где-то на стороне?

A>А вообще, какая разница?
A>Не, я знаю, что реализовано по-разному, но с точки зрения пользователя разница какая?

Какая-то есть, видимо. В винде симлинки не каждому разрешено создавать

Здравствуйте, ononim, Вы писали:

O>Директории и имя файлов — можно считать такими иерархичными тегами, раз тебе концепция тегов нравится, а имя — обязательный тег.
O>А для любителей множества тегов на один файл — есть ссылки.

В Windows есть ярлыки, но это не равнозначные теги. Остальное только через командную строку, чем мало кто пользуется.

Здравствуйте, Shmj, Вы писали:

S>В Windows есть ярлыки, но это не равнозначные теги. Остальное только через командную строку, чем мало кто пользуется.

В Windows и хабра нет

Здравствуйте, Shmj, Вы писали:

S>Типа теги. Как в RSDN каждый пост только в одной ветке дерева. А на Хабре — можешь один пост добавлять в n хабов одновременно.

в макос уже много лет как добавили "типа теги". Почему (не) пользуешься?

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
S>Вроде есть не древовидные файловые системы, но особо не получили признания.

У меня есть товарищ, который во времена универа не заморачивался каталогизацией — до 10 тыщ файлов могло лежать в одной единственной директории. Он не знал, что у него есть, а чего нет — когда что-то было нужно, обращался не к своей помойке, а к друзьям/одногруппникам/соседям по общаге.
Однажды он сел за мой комп — нужно было воспользоваться какой-то софтиной. Я ему сказал поискать в папке с дистрибами, типа где-то было. Он сказал, что у меня в дистрибах ВООБЩЕ НИЧЕГО НЕТ, и что у меня вообще винт пустой. В ответ на это я сел и за 30 секунд нашёл — удивлению не было предела. В отличие от его помойки, на моём винте директории были крохотными, но с глубокой вложенностью.

А потом я узнал про Стива Джобса.

...работа с файловой системой — это реликт прошлого, который слишком сложен для обычного пользователя.

Пользователи не должны искать файлы в папках; приложения сами должны управлять своими данными. В качестве примера он приводил iTunes (музыка внутри приложения) и почтовые клиенты (письма не хранятся в папках на диске пользователем вручную).

На конференции WWDC 2011 Джобс подтвердил, что компания уже 10 лет работает над тем, чтобы «избавиться от файловой системы».
В macOS это проявилось в виде функции Versions и автоматического сохранения, а также интеграции с iCloud, где файлы привязываются к конкретным приложениям, а не к путям на диске.

Да, я одно время пользовался макосью и файндером в т.ч.. И я точно могу сказать: почти всё, что я узнал про макось, я узнал не по своей воле.
Я был бы счастлив не знать, что такое файндер — всё(!)что я узнал про него, я узнал не по своей воле.

И это именно благодаря этому любителю кислоты и яблок распространился подход, когда у каждого приложения свои данные, и работать одновременно разными приложениями над одними данными не получится.

ЗЫ: Скажи а ты правда не знаешь и не понимаешь? Если что, я не хочу отвечать на твой вопрос, вот на тот, который я жирным выделил.

Здравствуйте, Marty, Вы писали:

M>Хз как в ваших линупсах, а в винде такое можно делать только в пределах одного тома, даже если все тома лежат на одном физическом диске. Симлинки такой хернёй не ограничены, но в винде, внезапно, по дефолту хардлинки делать можно на уровне пользователя без проблем, а симлинки требуют админских прав, или что-то там подкрутить в настройках системы. Кстати да, может мне кто-нибудь объяснит эту херню?

В венде вроде junctions можно делать, не будучи админом.

В линухе есть своя придурь: нельзя делать хардлинки на директории.

Здравствуйте, alpha21264, Вы писали:

A>В Линуксах всё проще. Ссылки можно ставить откуда угодно куда угодно. Дерево файловой системы общее, буковок нету.
A>Если диск (флешка) отмонтированы, то ссылка указывает в пустоту (и показывается красным цветом).

Ээээ. Никогда не сталкивался с разбиением диска на тома?

Дерево-то общее, но хардлинк может быть установлен только в пределах тома.

Здравствуйте, alpha21264, Вы писали:

A>Говорят, что в пределах диска.
A>А вообще, какая разница?
A>Не, я знаю, что реализовано по-разному, но с точки зрения пользователя разница какая?

Симлинк ломается при переименовании чего-нибудь в пути его target-а.

По сути, симлинк — это маленький текстовый файл, который интерпретируется, как ссылка на файл. И при переименованиях никто не следит за целостностью симлинков.

Здравствуйте, Marty, Вы писали:

A>>Говорят, что в пределах диска.

M>Не врут? Хардлинк — это же просто запись в каталоге и инкремент inode, разве это может быть где-то на стороне?

В пределах файловой системы.

M>Какая-то есть, видимо. В винде симлинки не каждому разрешено создавать

Не доверяет вам Билл Гейтс. Считает, что без админского диплома вы симлинков не осилите

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

А у тебя носки дома тоже могут одновременно на нескольких полках храниться?

Хорошо, когда у каждого предмета есть своё место. Иначе свихнёшься, когда предметов много.

Здравствуйте, Hоmunculus, Вы писали:

H>Потому что наше сознание иерархично. И само бытие иерархично. Как бы всякие анонимусы2 ни пытались все замешать в серую однородную каловую массу

Ну, строго говоря, оно иерархично в контексте. При смене контекста может измениться и иерархия.

Если относиться к файловой системе как к месту, где хранятся вещи, то всё довольно логично: на этой полочке носки, на этой — трусы, а на этой — патроны для дробовика. А вот засовывать в древовидную иерархию всё, как это предлагает делать ООП, не всегда бывает удобно.

Pzz>А у тебя носки дома тоже могут одновременно на нескольких полках храниться?
кстати не помешал бы тег, связывающий каждый носок с его парным экземпляром

Здравствуйте, ononim, Вы писали:

Pzz>>А у тебя носки дома тоже могут одновременно на нескольких полках храниться?
O>кстати не помешал бы тег, связывающий каждый носок с его парным экземпляром

Но в принципе можно обойтись и вложенностью — вкладывать один носок в другой

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
Легаси. Первые файловые системы были плоскими. Древовидные появились позже, и это позволяло файлы группировать.

В принципе у меня у самого мысли сейчас, что в современной файловой системе можно было бы попробовать организовать в виде тегов. А под капотом это уже не важно как, при необходимости можно было бы трансформировать в древовидное представление и какое угодно. Но по существу уже нет особого смысла что менять, это уже вопрос представления. Можно оставить дерево первичным, а на него навешивать теги. Сейчас собственно именно так и делают. А в теории можно и наоборот.

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
1. Иерархическое дерево/файловая система.
2. Система контроля версий.
3. Реляционная БД.

Все многообразие "гениальных идей", которыми пышут подавляющее большинство архитекторов, так или иначе сводится к одной из этих трех.

Здравствуйте, SkyDance, Вы писали:

S>>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

SD>Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.

Это типа граф?

SD>3. Реляционная БД.

SD>Все многообразие "гениальных идей", которыми пышут подавляющее большинство архитекторов, так или иначе сводится к одной из этих трех.

А как же ключ-значение?

S>А как же ключ-значение?

Это начальная стадия реляционной БД. Все K-V в итоге превращаются в (недоделанные) реляционные.

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева?

Удобнее всего в виде линейного списка до 5-7 элементов, а дальше емкость внимания начинает мешать. Потому приходится сворачивать в под элементы — такой прием вообще везде, например на куртке карманы, в кармане кошелек, в кошельке отделения, в отделениях деньги-записки-карточки

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

Здравствуйте, SkyDance, Вы писали:

SD>Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.
SD>3. Реляционная БД.
Есть объектно-ориентированные БД, вернее сказать DDL — data definition language, e.g EXPRESS. Конкретные реализации БД могут смешивать иерархический подход и реляционный — например PostgreSQL. Системы контроля версий это вариации двух других.

В сухом остатке все можно выразить графом или реляционной моделью.

Здравствуйте, Shmj, Вы писали:

S>В Windows есть ярлыки, но это не равнозначные теги. Остальное только через командную строку, чем мало кто пользуется.
Этим "остальным" пользуются примерно все. В рамках повседневного опыта — через подсистему SxS.
В рамках девелоперского — через менеджер пакетов pnpm, который экономит овердофига места и времени по сравнению с npm.
Иногда даже вручную — если хочется добиться того же эффекта, что и у этих инструментов, то делаем через Far, в котором всё это очевидно.

Почему мало кто делает это осознанно — потребности нет. Вот у вас тоже такой потребности нет, иначе бы вы (со своей-то разработчицкой подготовкой) знали о такой возможности и пользовались ей.

Здравствуйте, SkyDance, Вы писали:

SD> ... существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.
SD>3. Реляционная БД.

С терминами бы определиться сначала.

А то как каша структур (#1) и систем (#2, #3) пока выглядит (к тому же некоторые #2 могут быть реализованны на базе #3 — явно одно из двух не фундаментальное

)

P>С терминами бы определиться сначала.

Согласен, после перевода на русский вышло как-то коряво.

P>А то как каша структур (#1) и систем (#2, #3) пока выглядит (к тому же некоторые #2 могут быть реализованны на базе #3 — явно одно из двух не фундаментальное

)

Так и задумано — из любых двух можно создать третье, но сказать, какое "более фундаментально", невозможно. Впрочем, на это уже указали ранее. Что, однако, не меняет изначальный посыл — очередное гениальное изобретение корпоративных software architect на поверку оказывается чем-то из этих трех.

Здравствуйте, SkyDance, Вы писали:

SD>Это начальная стадия реляционной БД. Все K-V в итоге превращаются в (недоделанные) реляционные.

Ну да, ну да...
А точка — это область, при правильном преобразовании системы координат. ))

Мог бы уже не пытаться выкручиваться тут, ты реально упустил этот кейз.

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

Ключевое слово "удобнее".
Таково устройство нашего ассоциативного мышления — от общего к частному и наоборот.
Мы не в состоянии одновременно держать в голове сразу много всего, поэтому вынуждены создавать иерархии понятий.

=======
С другой стороны, здесь правильно подметили, что ассоциативность порождает в общем случае множество отношений, поэтому, папки "фотографии за 2024-й" и "фотографии с мариной" могут содержать копии (или ссылки/линки на одни и те же файлы).

Но теория отношений чуть сложнее, чем по зубам каждой домохозяйке, поэтому простая иерархичность интуитивнее, конечно.

	От:	Shmj
	Дата:	31.12.25 05:36
	Оценка:	-1

	От:	Hоmunculus
	Дата:	31.12.25 05:37
	Оценка:

	От:	Shmj
	Дата:	31.12.25 06:05
	Оценка:

	От:	Hоmunculus
	Дата:	31.12.25 06:07
	Оценка:	+1

	От:	Shmj
	Дата:	31.12.25 06:46
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	31.12.25 08:44
Оценка:	+4

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	31.12.25 10:13
Оценка:	+1

От:	Философ	http://vk.com/id10256428
Дата:	02.01.26 22:05
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	02.01.26 23:52
Оценка:

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	04.01.26 20:49
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	05.01.26 10:51
Оценка:

	От:	ononim
	Дата:	01.01.26 08:49
	Оценка:	+1

	От:	fmiracle
	Дата:	01.01.26 16:27
	Оценка:	+1

	От:	fmiracle
	Дата:	01.01.26 16:31
	Оценка:	+1

	От:	ononim
	Дата:	01.01.26 16:44
	Оценка: