У меня такой вопрос , наверное это не в тему по PHP: всё же из баз данных лучше использовать уже существующие СУБД или свою структуру из файловой системы с дескрипторной таблицей. Вопрос возник после прочтения вот этой "статьи" http://www.ahp-net.ru/cmsbuild.ahp
Нет в поиске.(или плохо искал) Вопрос в плюсах и минусах для СУБД и для файловой системы. СУБД против файлов так сказать.
так это смотря как с файлами работать, html страничка будет грузится быстрее чем html страничка из БД
То есть получается один плюс в пользу файлов содержащих html-код. Каждому своё место, где СУБД лучше использовать а где файловую систему.Только никак не пойму СУБД с чем, и как справляется гораздо лучше и быстрее?
с текстом вообщем так, самое лучшее это использовать и БД и файловую систему... в ФС, картинки, файлы, стоит так же кешировать тяжёлые запросы
Блин спасибо!!! Всё это время как раз меня и мучал этот вопрос , но я сам о нём не знал Разделение в хранении контетнта!!! Спасибо!!! Если не трудно есть какие то ссылки на НОРМАЛЬНОЕ изучение CMS?
В статье рассматривается вариант, когда на одну страницу один файл. Но на деле все по-другому. На одну страницу надо подгружать разные данные из БД. СУБД оптимизирована под эти задачи, в ней есть множество готовых решений. Стоит усложнить сайт на файлах и понадобиться еще один файл - индексный. Да и к тому же, в базе данных может быть запросто миллионы записей, а в файловой системе столько файлов быть не может (в php ограничение). Листинг такой папки будет очень долгим.
Здесь как раз и используется индексный файл(дескрипторная таблица). Но то что есть ограничения в самом PHP то .... это уже меняет дело.А если сделать "симбиоз" опять же некоторые "тягомотные" таблицы использовать в файлах.
Сейчас разрабатываю сайт, где будет выводиться порядка 100 товаров. Для реализации этого вывода и отрисовки страницы используются 8 запросов. Но я сделал кэш: отрисованная страница с прайсом кладется в файл и пользователь грузит Html оттуда, если в базе те же данные. Количество запросов уменьшилось до 3 (простых). В данном случае файловая система выигрывает у базы. Вы попробуйте написать сайт на файлах (обычный - статьи + новости (с лентой) + галерея фотографий + возможность любому написать статью с подгружаемыми картинками). А после этого попробуйте воспользоваться базой данных, сделав клон сайта. По собственному опыту скажу, что больше практически никогда не будете использовать файловую систему.
Значит дело в трудоёмкости и затратах времени? Спасибо за идею(написания сайта)!Я только учусь А новости с лентой(т.е. RSS???) где можно почитать или посмотреть код, если можно плз.
Не, обычный список анонсов к новостям. Да. Даже если твердо стоять на мысли "файлы - моё всё", то при написании сложного сайта, файловая система все равно приблизится к структуре БД. Поэтому писать базу данных на файлах - только время тратить. Да и знания для написания хорошей БД должны быть соответствующими: нужны универсальные алгоритмы для поиска, выборки, оптимизации.
Еще важный момент, что БД не просто возвращают данные - в запросе указывается, что именно надо получить. А если у вас индексный файл, то его надо отпарсить, парсинг на php, поверьте, работает гораздо медленнее, чем на си, на котором написана СУБД Более того - система хранения данных в БД отшлифована отличными программистами, неужели вы сделете лучше? )
!!!Вот и вывод (плюсы и минусы, скорее плюсов к СУБД больше) Спасибо что действительно прояснили на выбор.Спасибо!
для маленького, не нагруженного хомяка вообще без разницы на БД или файлах. Для проекта покрупнее тоже можно исхитриться и обойти проблемы с количеством и сложность вытягивания информации. Вопрос только в том, а надо ли оно? Никто не мешает написать систему, которая будет сама контролировать кол-во и размер файлов в папке, создавать индексную структуру, при очень большом желании можно даже свою систему запросов навернуть… Вот только это уже будет не «сайт на файлах», а сайт с относительно полноценной СУБД (скорее всего иерархическая база получится) Во, вспомнил. Файловая система — это тоже иерархическая БД. * задумался, кого бы подбить написать, чтоб проверить…
Скажу по опыту работы. При узкоспециализированных (читай - четко описанных) под задачу построение бд на файлах является более (сильно) выигрышным решением по скорости. business case: нужно получать очень много событий (например SNMP trap и прочих данных с других каналов) в единицу времени. СУБД завалит эту задачу. Файлы справляются. если совсем по теме: я тут как-то думал, как хранить данные. Чисто эмпирически решил использовать лимит, если строка больше 1024, то в файл. Ну это я чисто условно, навскидку. Надо будет потом научно подойти и ввести более разумный лимит. (в основном это касалось html кода. Аттрибуты для объектов (типа картинка) такие как описание (или автор) вне зависимости от длины в базе.
а потом появилось понимание «динамики» и «статики», кэширования, в конце концов пришёл к выводу, что ФС и БД — это не отдельные заменяемые средства хранения информации, а общая система угадал?
Luge ФС и БД: Ну такие основы я конечно знаю, "не первый день замужем" (c) Кэширование: Но Пока слишком сильно для меня - я начинающий (если про php) Просто в голове осело - данные типа: написал человек статью -> в файл -> индекс в базу создал человек html (в cmf или как там правильно) -> в файл -> индекс в базу картинка -> файл -> индекс в базу Ну и прочие крупные объекты, смысла хранения которых в базе нет (это имхо). Вот думаю пока - где проводить черту к чему я тут распалился-то Просто в голове уже мелькают куски собственного CMF (если я правильно употребил эту аббревиатуру - создание сайта из админки с пользователями, модулями и тд). Чувствую, скоро их надо будет ловить, собирать и проектировать начинать )
Дико польщен вниманием. А, конечно, М, но успел расстрелять 20 лет жизни на возню с базами данных. Итогом стала банальность, которая и изложена на сайте: всё хорошо на своём месте. В сложных манипуляциях данными - разумеется, СУБД. В простых случаях... не стоит забивать гвозди с помощью экскаватора. Молотком проще и быстрее. Так и здесь - для простейшего движка не нужны огромные ресурсы СУБД. Что до ссылки на эксперименты [vs] - это немножко смешно. Нужно же учитывать особенности работы ФС, незачем сканировать директорию и перечитывать в ней все файлы по очереди. Особенно когда имя нужного файла уже известно. Описанный мной движок при 10000 страниц в файлах спокойно будет работать быстрее БД по одной простой причине. Данные лежат в файле, обращение к нему идет по имени с заранее известным путем. Директория не сканируется (я не выжил из ума, чтобы соревноваться с СУБД таким заведомо проигрышным способом). Есть "индексный" файл (упакованный массив дескрипторов страниц), парсинг его делается куда быстрее, чем кажется (чтение в массив). Там и лежат номера, входящие в имена файлов данных. Не будем забывать, что отписанная на чистом Си СУБД делает еще массу телодвижений, которые нужны не всегда. При этом (в случае MySQL) точно так же лезет в три файла - из .frm вытаскивает и парсит структуру таблицы, из .myi вытаскивает индекс и тоже парсит, затем ищет в нем нужную(-ые) запись(-и) - и наконец, лезет в .myd и вычитывает нужные участки этого файла. Парсит считанное, пакует в ресурс (ассоциативный массив, по сути) и торжественно отдает в дальнейшую обработку. А потом уж php так же точно парсит этот массив, выколупывая значения полей. Если вспомнить, что перед этим СУБД нужно еще интерпретировать SQL-запрос, то быстрее уж точно не получится - чудес не бывает. Картина меняется, если нужна сложная выборка из множества таблиц - тут СУБД вне конкуренции. Поэтому движки интернет-магазинов, к примеру, я делаю на связке php/MySQL и не выпендриваюсь. На прощание советую заглянуть еще и на http://nanocms.name/ - там представлен движок, который имеет функционал намного сложнее. База тоже файловая, но работает, тем не менее, шустро.
AHP-net Не влезаю в дискуссию, просто обращаю внимание на 1 момент... Как раз для того, чтобы найти файл по известному пути и имени, и надо просканировать директории - от корневой до директории, в которой лежит файл. Сканирование последовательное, т.е. из записи файлов дергаются имена один за другим и сравниваются. Если нужный файл лежит в папке из 10000 файлов, и запись для этого файла идет в папке последней, то будут перелопачены все 10000 записей. Конечно, это быстрый процесс, т.к. все на уровне ФС, но тем не менее.
Нет, все-таки придется влезть Это делается только один раз за все время жизни демона MySQL, а не перед каждым запросом, так что это не считаем. Жесткому диску тоже надо сначала разогнаться, чтобы заработать Индекс никогда не вытаскивается целиком, и парсить там тоже нечего. Шаг только один: найти в дереве индекса нужную запись, результат поиска - "адрес" записи в файле данных. Фрагменты индекса кешируется в памяти. Ну, обычно "рваных" записей в таблице не бывает (а если их много - сделайте OPTIMIZE TABLE), поэтому речь не об участках, а о быстром чтении самой записи. Все остальное - обработка, превращение в ассоциативный массив - ничтожные затраты по сравнению с той же операцией файлового чтения. Единственное действительно узкое место - это канал передачи. Если PHP и MySQL находятся на разных машинах, возможны издержки. Но обычно все намного проще и быстрее.