Откуда берутся папки

ЕСТЬ РЕШЕНИЕ ЗАКРЫТО
#16 7 февраля 2018 в 10:46

это не прихоть разработчиков, а проверенная временем практика

Val
Каждой задаче — свой подходящий инструмент. Вы же не будете заказывать Камаз, если Вам нужно перевезти один мешок картошки? Я уже неоднократно показывал, что для подавляющего большинства сайтов текущий вариант слишком избыточен.

какой массив быстрее перерать в сто или тысячу значений?

Val
1. Для индексированных массивов эта проблема нивелирована. А все современные файловые системы — индексированные, в них нет перебора всего списка.
2. Если оставить только один уровень папок (опционально), то при 100 файлах в папке это 25 тысяч файлов на пользователя — на порядок больше, чем обычно нужно. Что проще, выбрать по индексу среди 1-100 файлов один раз (на одном уровне) или выбрать один раз из 1-256 (2-й уровень папок) и второй раз из 1-2 файлов? По любой логике, первый вариант будет быстрее. Но даже если это и не так, то всё с лихвой компенсируется уменьшением нагрузки на сервер в разы при ежедневных операциях обслуживания.

Я не отрицаю что папки создаются! Их много, но это не смертельно!

Val
Да ничто в движке сайта не смертельно для человека. 😊 Но большие проблемы всегда начинаются и складываются из мелочей. Просто не пойму, что мешает позаботиться о том, чтобы убрать эту мелочь и дать возможность вебмастерам самим решать, какой вариант им больше подходит?

но что вы делаете каждый день с файлами?

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

Далее, админ сайта также заинтересован иметь вторую ежедневную копию сайта в другом месте (дома, на офисном хранилище, на другом хостинге). И в этом случае может быть выгоднее делать инкрементное копирование, а не архивировать папку сайта целиком. А это уже второй проход по папкам. С этим уже столкнулся я. Хотя пока это не сильно напрягает, но зачем усугублять процесс, если несколько строк кода всё решат и в принципе уберут создание лишних папок?

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

Это стандартная практика.

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

Нет никакой "стандартной практики", Val. Есть только то, что удобнее в каком-то конкретном случае. (Смотрите пример про Камаз выше). В ситуации, когда пользователи за всё время жизни на сайте сохраняют в лучшем случае по сотне-тысяче файлов, более удобен более простой вариант, чем сейчас. Двухуровневый вариант удобнее только разработчикам движка. Всё, что я предлагал — это дать возможность админам сайтов выбирать подходящий вариант без патчей ядра. Ведь во всей Двойке подход именно такой — минимум правок системных файлов, максимум доступных настроек или возможность изменить что-то внешним кодом (например, хуком). Это, кстати, одно из величайших удобств Двойки, фактически её стандарт. И тут разработчики почему-то отошли от своего стандарта.


Полагаю, что дальнейшее обсуждение данной темы рискует пойти по очередному кругу, не вижу в нём смысла. Всем большое спасибо за участие в теме и её обсуждении. Я для себя нашёл вариант решения, который меня устраивает. Просто добавлю очередной патч, которого могло бы не быть. А остальное — дело и право разработчиков и других пользователей системы.
#17 7 февраля 2018 в 12:32

Я для себя нашёл вариант решения, который меня устраивает. Просто добавлю очередной патч, которого могло бы не быть.

Очень хорошо, что вы мониторите ситуацию, ибо вы пришли к 1 посту этой темы.

Вывод: вариант не подходит.

Вы за всех делаете этот вывод?
#18 7 февраля 2018 в 12:44

Как я понимаю МегаРостов пока единственный у кого возникли проблемы в первую очередь с запретами хостера!

Val
ПОКА единственный. Этому есть простое обьяснение: двойка сравнительно недавно обрела или почти обрела полную мощь. Многие долгое время не использовали ее по полной, (то есть как многопользовательский движок) из за отсутствия нужного функционала: модерации, полноценных групп, полноценных альбомов. Нельзя давать людям права на сайте, если у тебя нет возможности ими полноценно управлять. Не связями едиными так сказать.
#19 7 февраля 2018 в 18:54

Каждой задаче — свой подходящий инструмент. Вы же не будете заказывать Камаз, если Вам нужно перевезти один мешок картошки?

WebMan
В нашем случае имеем Газель (в среднем по больнице может справится с задачами перевозки людей и грузов), а вы предлагаете превратить её в Камаз (именно во что-то монструозное путем нагромождения лишней логики кода) а не легковой автомобиль.

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

WebMan
Как раз наоборот! Текущий вариант оптимален для БОЛЬШИНСТВА сайтов именно своей гибкостью. Вы же предлагаете допилить логику именно для решения конкретных узких задач.

1. Для индексированных массивов ...

WebMan
Откройте по ФТП с удаленного сервера папку содержащую 100 файлов, а затем 1000 и сравните. Цифры абстрактные, если 1000 тянется норм — откройте с 10000.

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

WebMan
Проблемы начнутся когда мастера выберут один вариант, а через некоторое время захочется другой, а потом третий.
Тут же все "из коробки" бери и пользуйся!
Вообще чем больше логики разделяющей поведение — тем сложнее поддерживать код. Зачем делать множественные условние if… если текущее решение обладает достаточной гибкостью.

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

WebMan
Бекапить БД соглашусь полезно. А все файлы — накладно. Если хостер может позволить делать бэкапы всего сайта — хорошо, пусть делает)) лишним не будет. Но логика подсказывает что по 100500 раз дергать файлы смысла нет. Гораздо практичнее на уровне кода (или настроек сервера) делать двойное сохранение загружаемых файлов в рабочий каталог и параллельно в бекап директорию на отдельном диске. Если рабочий накроется, то все быстро и легко восстанавливается со второго. Да этот вариант не для шаред-хостинга.
Но постоянно перекачивать 100500 файлов хоть они в одной дирректории хоть в разных задача не благодарная. Как сказал — если хостер это делает — лишним не будет.

Если МегаРостов столкнулся с проблемой — то решение очевидно либо искать проблему в стороннем коде, либо увеличивать лимиты хостинга. Обычно железо обходится дешевле ;)

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

WebMan
Наверное по всем файлам? ;)


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

WebMan
Стандартный — значит для широкого круга потребителей. И, как раз, в этом случае надо выбирать проверенные решения, которые будут устраивать многих. Многих != Всех. Кому не подходят какие либо решения волен допиливать под личные нужды.
Мне также не все подходит что есть "из коробки", но когда решил делать сайт на базе ЦМС я понимал что столкнусь с рядом ограничений "универсальности".
Поэтому стоит отличать мух от котлет и понимать какое внедряемое в ядро решение будет универсальным а какое решает только частные задачи. Разработчики всеми руками ЗА если предлагаемое решение действительно направлено на универсальное улучшение функционала. История выхода новых версий InstantCMS 2 это подтверждает.
Я уже много раз просил вас поискать информацию о том как решается подобная задача в других проектах! Вы же хотите переизобрести велосипед.

Нет никакой "стандартной практики", Val.

WebMan
Паттерны проектирования — это один из многочисленных[\b] примеров "стандартной практики" ;)

Есть только то, что удобнее в каком-то конкретном случае. (Смотрите пример про Камаз выше).

WebMan
Мы вообще про "частное" или "общее" ведём диалог? В каком-то конкретном случае удобно какое-то конкретное решение — никто не спорит! Но CMS — это не конкретный случай, а общий! Решение должно удовлетворять не конкретному абстрактному пользователю, а максимально бОльшему их количеству.

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

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

Всё, что я предлагал — это дать возможность админам сайтов выбирать подходящий вариант без патчей ядра.

WebMan
Я предлагаю вообще не парится и просто наслаждаться текущей стабильной отлаженной работой. Минимум настроек — максимум функционала!

Ведь во всей Двойке подход именно такой — минимум правок системных файлов, максимум доступных настроек или возможность изменить что-то внешним кодом (например, хуком).

WebMan
Правка системных файлов — это плохо не только в двойке, но и в первой ветке инстанта, и вообще в любом другом стороннем коде! Другими словами — не знаешь — не лезь! Правишь — принимаешь на себя ответственность поддержки своих правок.

Это, кстати, одно из величайших удобств Двойки, фактически её стандарт. И тут разработчики почему-то отошли от своего стандарта.

WebMan
Механизм хуков далеко не инновация двойки. За долго до нее они применялись и применяются во многих проектах, библиотеках и фреймворках. Опять же кроме хуков есть множество других механизмов выполнения стороннего кода "внутри" вендорного, но это совсем другая история.

Полагаю, что дальнейшее обсуждение данной темы рискует пойти по очередному кругу, не вижу в нём смысла.

WebMan
Согласен. В теме я высказал свое мнение, потому что отчетливо заметил лобирование личных интересов — "кто-то что-то поломал у себя и под шум накидываем хотелок, и побольше, побольше!"

ПОКА единственный. Этому есть простое обьяснение: двойка сравнительно недавно обрела или почти обрела полную мощь. Многие долгое время не использовали ее по полной, (то есть как многопользовательский движок) из за отсутствия нужного функционала: модерации, полноценных групп, полноценных альбомов. Нельзя давать людям права на сайте, если у тебя нет возможности ими полноценно управлять. Не связями едиными так сказать.

@Zolo
facepalm
#20 7 февраля 2018 в 18:55
Да-а-а… краткость не моя сестра scratch
#21 7 февраля 2018 в 19:49


Да-а-а… краткость не моя сестра scratch

Val

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

Поповоду папок, думаю многие узнав о такой особенности движка, как минимум призадумались что делать чтобы избежать подобной потенциально возможной ситуации.
#22 7 февраля 2018 в 20:03

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

@Zolo
А вы?

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

@Zolo
При чём тут права гостей и обсуждаемая тема?

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

@Zolo
Скажите, какой ситуации нужно избежать? Еще раз диктую большими буквами: НЕТ проблем с директориями от слова совсем. То, что тут люди со странной фантазией написали, говорит лишь о малой компетенции в обсуждаемом вопросе.

Еще раз: проблемы с хранением файлов НЕТ и не было.

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