Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Общие вопросы > XML в качестве бд для сайта визитки

Автор: Just123 24.1.2012, 14:54

Добрый день уважаемые винградочане Делаю простейшую систему управления контентом сайта, для сайта визитки. Из функционала только статические страницы, новости и галерея. Не хочу использовать в качестве базы данных MySQL(никогда ни с че другим не работал) т.к. нет в ней надобности, но никак не могу решить, как хранить данные? Не хотелось бы устанавливать дополнительные расширения, поэтому остановился на следующих вариантах:  XML  Файловая бд И вот собственно вопрос знатокам,  на сколько целесообразно хранить данные в XML? или лучше использовать бд основанную на текстовых файлах? Или возможно вы подскажете другой, более целесообразный способ хранения данных? Хранить потребуется следующие данные: [Статические страницы] - Заголовок - Дата создания (желательно) - Дата изменения (желательно) - Содержание страницы (с HTML тегами) [Новости] - Заголовок - Дата создания - Содержание новости (с HTML тегами) Спасибо за уделенное время. P.S. Глюкнуло и почему-то создалось 2 темы, снесите вторую пожалуйста.

Автор: $дмитрий 24.1.2012, 15:54

Цитата Делаю простейшую систему управления контентом сайта, для сайта визитки. Лучше б взял какой-нибудь фрейворк/кмс Цитата Или возможно вы подскажете другой, более целесообразный способ хранения данных? Ну конечно используй БД, о чем разговор. Без нее будет сложнее развивать продукт Цитата И вот собственно вопрос знатокам,  на сколько целесообразно хранить данные в XML Из достоинств XML - Предоставляет структуру - В php есть функции для управления этого дела Из недостатков - будет тормозить на больших файлов - скорость парсинга меньше чем другие форматы Ну его в пень этот XML, накройняк используй JSON/Serialize Цитата - Содержание страницы (с HTML тегами) Не вздумай пихать это в XML

Автор: ksnk 24.1.2012, 15:57

Just123, Какие потребности у сайта-визитки по работе с данными? Вывод новостей по группам/по дате? Обновление визитки предполагается частое? Если комплект страниц сайта ограничен  и редко изменяется - можно обойтись файловым кэшированием. Все страницы генерируются админкой или при первом просмотре. В каком виде при этом хранятся данные для генерации сайта - без разницы, хоть сериализованный массив... Ничем не хуже xml, imho   Еще довольно прикольный способ - var_export для хранения данных в родном PHP массиве. То есть нужно выяснить что-же потребуется от базы данных, объем этих данных...

Автор: Just123 24.1.2012, 21:01

ksnk,  Цитата  Какие потребности у сайта-визитки по работе с данными? Вывод новостей по группам/по дате? Обновление визитки предполагается частое? Вывод новостей по дате, остальное это просто ввод, вывод, редактирование информации. Обновление вряд ли будет больше нескольких раз в месяц. Что касается объема, данные не очень большие, но в массив целую страницу не оч. хочется пихать, поэтому хранить думаю в файлах, вот только в каком виде хранить, не знаю, почему-то пока больше симпатизирует XML из-за удобства работы, а скорость вообще не в приоритете т.к. не сомневаюсь, что больше 10 хостов в неделю на сайте будет)). $дмитрий, Тут смысла в фреймворке нет, простейшая реализация ядра + модуль стат. страниц и модуль новостей, даже админки как таковой не будет(как пример Livestreet). Цитата Ну конечно используй БД, о чем разговор. Без нее будет сложнее развивать продукт Боюсь, вы не понялию. Разговор о том, какую использовать БД и в каком виде хранить данные?   Цитата Не вздумай пихать это в XML Почему? Можно же хранить это как символьные данные и проблем не возникнет. Поправьте пожалуйста, если я ошибаюсь.

Автор: Sentox 25.1.2012, 00:42

Цитата($дмитрий @ 24.1.2012,  15:54) Ну его в пень этот XML, накройняк используй JSON/Serialize Чего то я не понял, при чём тут упаковка javascript notation на сервере?

Автор: Sentox 25.1.2012, 01:00

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

Автор: ksnk 25.1.2012, 07:16

Just123, XML в качестве базы не очень удобен, потому, что SimpleXml сохраняет его в не очень читаемом виде (без форматирования) так что редактировать его вручную все равно практически невозможно. Если предполагается иногда редактировать файлы вручную (иначе зачем вообще использовать текстовые файлы для хранения?) то более удобным будут ini-файлы. функция записи ini файла где то в комментариях http://php.net/manual/en/function.parse-ini-file.php встречалась.

Автор: Gold Dragon 25.1.2012, 07:26

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

Автор: Just123 25.1.2012, 09:32

А что если сделать следующим образом: Содержание новостей и страниц, хранить в txt\ файлах, а в XML или INI хранить ID, тип, заголовок. На основе данных из XML\INI можно генерировать список новостей и прочее, а само содержание будет храниться в отдельном текстовом файле. (Содержание будет отображаться только после клика на заголовок(перехода на новую страницу)) Как вам такая схема работы? Или я уже совсем не в ту степь?))

Автор: Sanchezzz 25.1.2012, 10:57

ksnk а если за место симпела использовать XMLReader то можно любой xml документ прочитать + он жрет памяти меньше и можно читать xml по 50mb Где simpleXML просто умирает.

Автор: ksnk 25.1.2012, 11:31

Цитата(Sanchezzz @  25.1.2012,  10:57 ) читать xml по 50mb  Если дело доходит до контекста в 50 mb, то тут уже не совсем сайт-визитка    Хотя с xml дело толком не имел, так что про XMLreader толком ничего не скажу. Just123, Как оно будет сделано - не важно. Делай как удобнее. Даже если будет очень долгая генерация страницы - файловое кэширование спасет любой тормозной движок.  Если данных в сумме много больше 10-20кб, разумно разбить на несколько файлов, с "логикой" и текстовыми кусками, просто чтобы часточитаемая логика читалась побыстрее, а ненужная текстовка - пореже, но собственное удобство должно быт важнее мифической эффективности по скорости. Понятно, что будет крайне разумно написать класс-обертку над логикой хранения данных, чтобы без сильной кровищи переходить на разные носители информации.

Автор: Just123 25.1.2012, 11:32

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)