Программирование[10]

[Just.Doit]

Index написал Только что:

Конкретно с точки зрения бизнеса у нас к ФС будет ридонли доступ (в виде сетевого диска) и стурктура должна быть хьюман ридабл и естественно повторять дерево с UI.

как тогда бд может быть источником истины? вы после изменения в бд пойдете в ФС все переставлять какой-то джобой?

 

зачем вам вообще ФС если она ридонли?

[Index]

Just.Doit написал 2 минуты назад:

зачем вам вообще ФС если она ридонли?

Не так сформулировал.

 

Ридонли доступ к ФС будет для пользователей. Сам сервис будет уметь и писать, и  удалять, и перемещать и тд и тп.

[Kant]

могу только скзаать, что в склсервере есть вот такое

https://docs.microsoft.com/en-us/sql/relational-databases/hierarchical-data-sql-server?view=sql-server-ver15

для идентификации деревьев

 

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

а дальше пусть фс как фс и отображается вебсервером или хз

[GoldRobot]

universal написал 2 часа назад:

так я и говорю, что для каждой таблицы нужен свой инкрементер, в таком случае

Он и должен быть свой, если тебе нужен в таблице ИД.

Написал сделал тип у таблицы bigserial и все?

 

Just.Doit написал 2 часа назад:

я не эксперт. но кажется вероятностью коллизий при "децентрализованной генерации"

 

Каких блдаж колизий? Между чем и чем?

 

И к слову замечу, что гарантию отсутствия колизий даст только uuid1 через локального демона.

 

 

Kant написал 4 минуты назад:

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

 

Базу не повешает?

Вот представь у тебя юзер говорит папочку "y" по пути "1/2/3/4/5/6/7" поместить в папочку "1/2/3/4/5". А там внутри папочки лежит 10000 файликов. И вот у тебя юзер сгенерировал довольно тяжелый запрос просто одним кликов, ведь тебе теперь нужно пройтись по стриговому ключу и его отмодифицировать.

[Grohuf]

GoldRobot написал 7 минут назад:

Базу не повешает?

Вот представь у тебя юзер говорит папочку "y" по пути "1/2/3/4/5/6/7" поместить в папочку "1/2/3/4/5". А там внутри папочки лежит 10000 файликов. И вот у тебя юзер сгенерировал довольно тяжелый запрос просто одним кликов, ведь тебе теперь нужно пройтись по стриговому ключу и его отмодифицировать.

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

[Kant]

вырезать и вставить новые  
ну вообще да, я про модификации не подумал, там индекс че-то про ридонли писал, я и забыл уже

[Kant]

Grohuf написал Только что:

GoldRobot написал 8 минут назад:

Базу не повешает?

Вот представь у тебя юзер говорит папочку "y" по пути "1/2/3/4/5/6/7" поместить в папочку "1/2/3/4/5". А там внутри папочки лежит 10000 файликов. И вот у тебя юзер сгенерировал довольно тяжелый запрос просто одним кликов, ведь тебе теперь нужно пройтись по стриговому ключу и его отмодифицировать.

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

тебе не нужна база, чтобы смотреть файлы

для этого есть файловая система, они для этого придуманы

база чисто метаданные хранить

[GoldRobot]

У нас кстати ДБА как-то на ltree захерачил рекурсию, было очено удобно.

[Just.Doit]

Kant написал 2 часа назад:

Grohuf написал 2 часа назад:

GoldRobot написал 2 часа назад:

Базу не повешает?

Вот представь у тебя юзер говорит папочку "y" по пути "1/2/3/4/5/6/7" поместить в папочку "1/2/3/4/5". А там внутри папочки лежит 10000 файликов. И вот у тебя юзер сгенерировал довольно тяжелый запрос просто одним кликов, ведь тебе теперь нужно пройтись по стриговому ключу и его отмодифицировать.

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

тебе не нужна база, чтобы смотреть файлы

для этого есть файловая система, они для этого придуманы

база чисто метаданные хранить

я думаю под содердимым папки и подразумевался просмотр метаданных файлов которые лежат в папке

[Grohuf]

Kant написал 9 часов назад:

Grohuf написал 9 часов назад:

GoldRobot написал 9 часов назад:

Базу не повешает?

Вот представь у тебя юзер говорит папочку "y" по пути "1/2/3/4/5/6/7" поместить в папочку "1/2/3/4/5". А там внутри папочки лежит 10000 файликов. И вот у тебя юзер сгенерировал довольно тяжелый запрос просто одним кликов, ведь тебе теперь нужно пройтись по стриговому ключу и его отмодифицировать.

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

тебе не нужна база, чтобы смотреть файлы

для этого есть файловая система, они для этого придуманы

база чисто метаданные хранить

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

[Kant]

этим эффективным хранилищем блобов является файловая система 

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

 

проблемы там начнутся намнооооооого позже проксирования фс, когда надо будет решать вопрос, а чё делать, если папка целиком не влезла на один сервер физический, но я так понимаю этот вопрос вообще не стоит, иначе бы не было фразы "сетевой диск" а сразу бы упоминалось про какой-нибудь блобсторадж

 

[Index]

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

А ещё метадата modify time высчитывать на основе max(modify time) метадаты детей 

[Grohuf]

Kant написал 10 минут назад:

этим эффективным хранилищем блобов является файловая система 

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

 

проблемы там начнутся намнооооооого позже проксирования фс, когда надо будет решать вопрос, а чё делать, если папка целиком не влезла на один сервер физический, но я так понимаю этот вопрос вообще не стоит, иначе бы не было фразы "сетевой диск" а сразу бы упоминалось про какой-нибудь блобсторадж

 

Ты какую то хуйню несёшь. Извини. Хотя второй абзац показывает, что админы минимально соображать умеют

Index написал 3 минуты назад:

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

А ещё метадата modify time высчитывать на основе max(modify time) метадаты детей 

Ты хочешь делать выгрузку всей базы, когда размер базы будет огромен?

Index написал 22 минуты назад:

не использовали стейт в o(N)

Строишь дерево в памяти из одних только id-шников, потом поэлементно дампишь инфу.

[Just.Doit]

Grohuf написал 3 часа назад:

лишь лишний слой дублирования информации, который рано или поздно, разъедется и будет доставлять головную боль.

тут пришла в голову идея что можно/нужно просто id-шник в ФС хранить (там же есть кастомные поля/метаданные в ФС) - тогда можно приложению при старте вычитывать ФС, проверять соответствие структуры, а сам блоб привязывать по idшнику если что-от поехало структурно. ну или наоборот - при старте перестраивать фс в соотвествии с тем что в приложении осталось - тут уже вопрос бизнесовых кейсов отказа/рассинхрона

еще кстати вопрос с версионированием... но наверное можно версию иметь в ФС мете вместе с идшником, сами файлы старых бросать без структуры в хранилище блобов и в приложении иметь ссылку на них

Изменено 26 ноября 2021 пользователем Just.Doit

[Grohuf]

Just.Doit написал 53 минуты назад:

тут пришла в голову идея что можно/нужно просто id-шник в ФС хранить (там же есть кастомные поля/метаданные в ФС) - тогда можно приложению при старте вычитывать ФС, проверять соответствие структуры, а сам блоб привязывать по idшнику если что-от поехало структурно. ну или наоборот - при старте перестраивать фс в соотвествии с тем что в приложении осталось - тут уже вопрос бизнесовых кейсов отказа/рассинхрона

Ты имеешь ввиду id метаданных из базы сохранять, например, в виде имени файла (чтобы не париться с кастомными аттрибутами), иерархическую структуру файлов хранить в виде папок в ФС, а в базе хранятся только метаданные? Ну можно так. А можно вообще хранить просто файлы парами "картинка.jpg"+"картинка.metadata" (это если не хочется париться с прицеплением к файлу доп данных средствами FS).

Тут же все зависит от того, что Index хочет сделать, чтобы быстрее всего работало.

Изменено 26 ноября 2021 пользователем Grohuf

[Drakonian]

Хуяришь все в sharepoint и через API все достаешь в любой последовательности xDDDDD

[madvlaydin]

Drakonian написал 44 минуты назад:

 sharepoint

майкрософт головного мозга

[intheairlove]

По советам юзеров зарегистрировался на hexlet, начал проходить 2 бесплатных курса "Введение в программирование" и "Жизнь программиста" (поковыряюсь пока в них, если почувствую что моё возьму подписку уже), буду по ходу дела отписываться тут, также спрашивая советов, либо напишу что пошло оно всё нахуй и самовыпилюсь из этого топика 

п.с. очень порадовало напутствие с 1 страницы топана по поводу вкатывания в айти 

[Just.Doit]

 

madvlaydin написал 9 минут назад:

Drakonian написал 54 минуты назад:

 sharepoint

майкрософт головного мозга

без актив директори и MS SQL Server задача не решаема ящитаю

Изменено 26 ноября 2021 пользователем Just.Doit

[madvlaydin]

Just.Doit написал 26 минут назад:

 

madvlaydin написал 35 минут назад:

Drakonian написал 1 час назад:

 sharepoint

майкрософт головного мозга

без актив директори и MS SQL Server задача не решаема ящитаю

 

ага, и старый .нет фреймворк