Есть ли смысл в переименовании индексного файла?

Добрый день!

Традиционно индексным файлом является index.php (index.html). Соответственно, сайт открывается по адресу http://localhost/ и по адресу http://localhost/index.php. И получается, как бы, два дублирующих адреса главной страницы, что нехорошо с поисковой точки зрения.

А с помощью DirectoryIndex мы можем сделать главной какую-то другую страницу, например main55.html. И тогда дублирования не будет.

Применяется ли это на практике?

0

Сообщение от Инженер_3 1. БД MySQL/Oracle менее надёжны, чем файлы в директории (сам наблюдал сбои в БД)

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

Сообщение от Инженер_3 2. Отдельные файлы в директории можно быстро заменить, а в БД так не получится, нужны танцы с бубном 3. Размер этих файлов в сумме не очень большой (там есть и графические файлы, которые в БД не разместить) - 10Mb без графики.

Медиафайлы и т.п. можно продолжать хранить в файловой системе (хотя и для этого есть специализированные базы данных). В базе данных хранятся все прочие данные.

Сообщение от Инженер_3 А чем плохо складирование данных в файлах?

Множество недостатков. Сложность поиска, отбора, управления содержимым, доступа к метаданным и т.п. Об этом много написано.

Сообщение от Инженер_3 Где-то читал, что применение БД обосновано, если объём данных >100Mb

Безосновательное утверждение. Почему не 150 Мб? Базы данных используются в визитках практически точно так же, как и в более крупных приложениях. Причем для визиток даже кэширование можно не применять, а использовать напрямую обычные SQL-системы (MySQL, PG, etc.), т.к. обычно у них небольшая посещаемость и в них используются простые SQL-запросы.

Сообщение от Инженер_3 У меня "погоняло" Инженер. Я инженер-конструктор по автоматизации производства. Только и занимаюсь, что упрощаю работу другим и себе. Хотя сайт пишу в Блокноте для полного понимания кода.

Тем более странно, что у вас до сих пор сайты не на базах данных работают. С такой профессией можно было множество инфраструктурных Web-сервисов внедрить, т.е. по сути таких же сайтов. Можно начать с простейших информационных сервисов (справочников).

Добавлено через 5 минут
У реляционных баз данных гораздо больше возможностей по структурированию данных, чем у обычных ФС. Если в ФС "расширенные атрибуты" - это сакральная сфера, то в базах данных это такие же поля, как и поле с "основным содержимым". В ФС многие не часто используют даже симлинки (для улучшения структурирования). Я тоже предпочитаю "покрыть" коллекции медиафайлов и т.п. базами данных, чем вникать во все возможности современных ФС.

0

Сообщение от estic А чем плохо складирование данных в файлах? Множество недостатков. Сложность поиска, отбора, управления содержимым, доступа к метаданным и т.п. Об этом много написано.

Сложность поиска, отбора, доступа к метаданным - зачем это мне?
Управление содержимым - зачем мне менять содержимое файла (или БД) на сайте? Проще заменить файл, который сформирован и быстро и правильно изменён на локальном компьютере.

Добавлено через 2 минуты

Сообщение от estic О надежности использования файловой системы при полноценном управлении содержимым разными пользователями даже говорить не стоит.

Хозяин должен быть один. А если их несколько, то даже самый современно-крутой сайт убьют.

Добавлено через 5 минут

Сообщение от estic Безосновательное утверждение. Почему не 150 Мб? Базы данных используются в визитках практически точно так же, как и в более крупных приложениях. Причем для визиток даже кэширование можно не применять, а использовать напрямую обычные SQL-системы (MySQL, PG, etc.), т.к. обычно у них небольшая посещаемость и в них используются простые SQL-запросы.

Про 100Mb - за что купил, за то и продаю, это информация не моя, а из инета (какого-то веб-мыслителя)
Что касается визиток на БД MySQL - если есть буратины, то почему бы их не пощипать.
Один программист говорил (лет 10 назад), что за строчку кода ему платят 0,50$, отсюда и навороченность сайтов с применением заоблачных технологий.

Добавлено через 5 минут

Сообщение от estic Тем более странно, что у вас до сих пор сайты не на базах данных работают. С такой профессией можно было множество инфраструктурных Web-сервисов внедрить, т.е. по сути таких же сайтов. Можно начать с простейших информационных сервисов (справочников).

Я профессиональный инженер-механик, а программирование для меня всего лишь хобби.
А создавать информационные сервисы в какой области? Механике? Глупо. На постсовке это не актуально, а за бугром свои стандарты.

0

Инженер_3, зачем конкретно вам, не знаю. Оно как бы всем нужно. Даже простые сайты нуждаются в "едином источнике данных", в "непротиворечивости данных" и т.п. Даже простая страница обычно содержит данные из разных источников, например элемент коллекции ссылается на соответствующую коллекцию (страница элемента содержит имя и адрес страницы коллекции). Если вы захотите изменить имя коллекции, вы будете 100500 страниц редактировать? В три часа ночи, чтобы поменьше пользователей было?

Добавлено через 5 минут

Сообщение от Инженер_3 Я профессиональный инженер-механик, а программирование для меня всего лишь хобби.

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

Добавлено через 5 минут

Сообщение от Инженер_3 А создавать информационные сервисы в какой области? Механике? Глупо.

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

0

Сообщение от estic Инженер_3, зачем конкретно вам, не знаю. Оно как бы всем нужно. Даже простые сайты нуждаются в "едином источнике данных", в "непротиворечивости данных" и т.п. Даже простая страница обычно содержит данные из разных источников, например элемент коллекции ссылается на соответствующую коллекцию (страница элемента содержит имя и адрес страницы коллекции). Если вы захотите изменить имя коллекции, вы будете 100500 страниц редактировать? В три часа ночи, чтобы поменьше пользователей было?

1. Стесняюсь спросить, а что такое коллекция? В моём лексиконе нет такого слова для программирования.
2. Я редактировать страницы на сайте не планирую, я их туда буду копировать обновлённо-изменёнными с локального компьютера.

Добавлено через 2 минуты

Сообщение от estic Кто не может создать, берет готовое. Глупо не использовать современные возможности. У меня, например, все книги домашней библиотеки занесены в базу данных, небольшое количество полностью отцифровано.

Вы предлагаете мне оцифровать всю литературу по механике и разместить её в интернете?

0

Сообщение от Инженер_3 Стесняюсь спросить, а что такое коллекция?

Вроде массива. Не забивай голову. Инженеру-механику это ни к чему

Сообщение от Инженер_3 Вы предлагаете мне оцифровать всю литературу по механике и разместить её в интернете?

Идея хорошая. Только сразу про авторские права уточни.

Сообщение от Инженер_3 зачем мне менять содержимое файла (или БД) на сайте? Проще заменить файл, который сформирован и быстро и правильно изменён на локальном компьютере.

Правильно. Делай, как проще. А как ты собираешься хранить комментарии? Неужели комментариев не будет на сайте?

0

Сообщение от Инженер_3 Стесняюсь спросить, а что такое коллекция?

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

Сообщение от Инженер_3 Я редактировать страницы на сайте не планирую, я их туда буду копировать обновлённо-изменёнными с локального компьютера.

Ладно Только учтите, что при таком подходе часто придется по полсайта копировать и примерно столько же информации держать в голове (зависимости текущей страницы).

Сообщение от Инженер_3 Вы предлагаете мне оцифровать всю литературу по механике и разместить её в интернете?

Это был просто пример. Вы не ведете рабочих записей, не строите "таймлайн" событий/действий или просто алгоритмы, не используете экспертные системы? Наверное, я плохо понимаю, что такое "инженер-конструктор по автоматизации производства".

Добавлено через 2 минуты

Сообщение от estic Характеризуется не только набором этих элементов, но обычно имеет и собственные метаданные.

Например, коллекция "Пользователи" содержит собственное имя и слаг ("user"), может содержать кэш с количеством пользователей, ссылается на таблицу пользователей (содержит ее краткое или полное имя).

Вот сборник примеров с этого форума: hyde.pageshop.ru/tables (в таблице на странице по ссылке представлен список коллекций; сама страница формируется на основе "коллекции коллекций", которая имеет имя "Таблицы", слаг "tables" и т.п.).

0

Сообщение от black1385 Вы предлагаете мне оцифровать всю литературу по механике и разместить её в интернете? Идея хорошая. Только сразу про авторские права уточни.

Так я этой фигнёй заниматься не буду. Мне это не надо.
Что касается авторских прав, то в СССР их официально не было, а литература изданная после 1991 года - полная туфта на 90%.

Добавлено через 1 минуту

Сообщение от black1385 Правильно. Делай, как проще. А как ты собираешься хранить комментарии? Неужели комментариев не будет на сайте?

А зачем мне комментарии? Под них нужно найти цензора, что бы потом не было проблем. Это лишний головняк.

Добавлено через 3 минуты

Сообщение от estic Только учтите, что при таком подходе часто придется по полсайта копировать и примерно столько же информации держать в голове (зависимости текущей страницы).

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

Добавлено через 5 минут

Сообщение от estic Вы не ведете рабочих записей, не строите "таймлайн" событий/действий или просто алгоритмы, не используете экспертные системы?

Рабочие записи веду - и на компе и в правильных блокнотиках.
Что такое "тимлайн" и экспертные системы не знаю.

Сообщение от estic Наверное, я плохо понимаю, что такое "инженер-конструктор по автоматизации производства".

Инженер-конструктор по автоматизации производства - данный специалист разрабатывает и внедряет в производство полуавтоматы и автоматические линии (ими занимается не один специалист) и всякое другое оборудование для облегчения работы трудящихся на заводах и фабриках и даже замещения их (самих трудящихся).

Добавлено через 8 минут

Сообщение от estic Например, коллекция "Пользователи" содержит собственное имя и слаг ("user"), может содержать кэш с количеством пользователей, ссылается на таблицу пользователей (содержит ее краткое или полное имя). Вот сборник примеров с этого форума: hyde.pageshop.ru/tables (в таблице на странице по ссылке представлен список коллекций; сама страница формируется на основе "коллекции коллекций", которая имеет имя "Таблицы", слаг "tables" и т.п.).

Ничего не понял, но очень интересно.
Может вместо "коллекция" использовать слово "массив" (как писалось выше по форуму)?
У каждого свой лексикон. Для меня коллекция - это коллекция одежды и коллекция марок и т.п.
А вместо коллекций коллекций создать структурный тип.

0

Сообщение от Инженер_3 вместо "коллекция" использовать слово "массив"

Есть такая песня ... Районы, кварталы, жилые массивы
Есть данные, одним словом... деревья, наборы файлов или/и + записей в некоторых оных...
Для удобства и упрощения доступа, поиска, и т.п.,,, удобно держать где-то метаданные, списки, индексы...
Практически та же База Данных... хоть и без всяких СУБД , чисто в скриптах и в служебных/вспомогательных файлах.

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

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

Минимально у меня помню в кажной папочке просто файлик опционально мог присутствовать... типа с точкой в имени,
в котором для всяких текст/аштеэмэл кодировка была... чтобы в бд трамбовать вытяжки чисто текста для полнотекстового поиска...
+ там название/описание ветки , чтобы типа дреаовидно/иерархически представить чем-то кроме имён в ФС.
... descript.ion и подобные файлы в windows тоже как вариант хранения доп. текста
... и в СУБД автоматизированно загнать из такого не проблема.
проблема только в том что меняя что-то из данных в ФС, чаще желательно параллельно менять что-то и в метаданных

0

Сообщение от Инженер_3 А какую информацию держать в голове - все страницы генерируются автоматически в index.php по информации из обновлённо-скопированных файлов.

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

Сообщение от Инженер_3 Может вместо "коллекция" использовать слово "массив" (как писалось выше по форуму)?

Используйте, что хотите. Я написал, что это термин из REST. REST базируется на HTTP.

Речь была даже не об объекте-коллекции (это уже из ООП, если что).

0

Сообщение от Инженер_3 Может вместо "коллекция" использовать слово "массив"

Тебе можно
А еще в ЯП бывают списки, кортежи, словари, множества, структуры, перечисления и др. Называй всё массивами... не заморачивайся

0

Сообщение от Инженер_3 А вместо коллекций коллекций создать структурный тип.

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

0