Forum Webscript.Ru
Программирование => PHP => Тема начата: FreeSpace от 15 Марта 2004, 21:33:11
-
CGVictor:
Разрабатываешь _свой_ фотмат для новостей, в котором тебе будет удобнее их редактировать.
Вот специально для таких "умельцев" придумали XML.
Угадай, что будет, если в тексте новости встретятся символы "||"?
Да, конечно, их можно экранировать, но имхо проще выучить XML.
-
FreeSpace, ты это серьезно написал?
-
Olegka
Если тебя устраивает такой вариант - используй на здоровье. Лишь бы ты понимал, как он работает и какие могут быть грабли в будущем.
RomikChef, вполне серьёзно.
Конечно, через "школу имплоудов/эксплоудов" все проходили.
Но почему бы не пропустить этот этап и не выучить нормальный, общепринятый формат хранения данных?
Хотя кроме XML есть другая альтернатива - использовать нормальную БД, хотя бы SQLite.
-
FreeSpace:
хотя бы SQLite.
да зачем проходить эту школу типа-СУБД.
пущай сразу оракл учит
-
AliMamed
Если это была ирония, то уловить её довольно сложно. Во всяком случае, для меня.
Оракл для такой задачи слишком тяжеловесный, а имплоуд/эксплоуд - слишком глючный и дилетантский.
Опять же, это моё ИМХО.
-
FreeSpace:
имплоуд/эксплоуд - слишком глючный и дилетантский.
ну во-первых.
имплоуд/экслоуд - это функции для работы со строками и массивами. отношение к хранению структурированных дынных они конечно могут иметь. алгоритм самих функций существует с 3 версии php и просто даже обидно слышать про их "глючность".
что дилетантского в хранении данных в флэт-файлах? при минимальной фантазии момент с "||" который тебя так раздражает решается без всякого как ты выразился "экранирования" с изяществом которое тебя поразит.
да с данными во флэт-файлах тяжело работать если их много и/или очень высока нагрузка. однако для небольших сайтов вполне приемлимы даже полнофункциональные цмски построенные на флэтфайлах.
иксэмл имеет свои преимущества, но например для того чтобы вывести одну рандомную из трех имеющихся строк абсолютно избыточен.
-
У меня нету ни малейших притензий к функциям implode и explode. Но у меня есть целый ряд причин, по которым я называю хранение данных в флэт-файлах в ТАКОМ виде весьма неоптимальным.
AliMamed:
при минимальной фантазии момент с "||" который тебя так раздражает решается без всякого как ты выразился "экранирования" с изяществом которое тебя поразит.
Порази меня, пожалуйста :) Мне действительно очень любопытно, о каком таком изяществе идет речь? Может ты решил предложить использовать рендомный boundary, как в multipart-мейлах? :)
По-моему хранить данные в таком виде - это всё равно что хранить изображения в БД. В принципе можно, но обычно не нужно.
Причин, по которым я выступил против такого подхода, много: начиная от быстродействия, заканчивая возможностью поиска, сортировки и т.д.
Здается мне, что тема может перерости во флейм и виновником окажусь я сам...
-
FreeSpace:
Порази меня, пожалуйста
могу для примера привести достаточно известный регистр
-
FreeSpace
ты посчитай время обработки текстового файла и сравни со временем разбора XML файла
Можт тогда поймешь в чем ты не прав
-
AliMamed:
могу для примера привести достаточно известный регистр
Приведи, если не сложно. Пока что я понятия не имею, о каком таком регистре идет речь.
ThE0ReTiC
Основная моя мысль - это не склонить автора темы к тому или иному формату хранения данных, а лишь объяснить ему, что такой формат, который он выбрал, является... не самым оптимальным. Кроме XML я назвал и SQLite на тот случай, если MySQL недоступен.
-
FreeSpace:
о каком таком регистре идет речь
http://spectator.ru/ насколько я понимаю, этот...
его движок: http://textus.ru/
-
Yukko:
FreeSpace: о каком таком регистре идет речь
http://nudnik.ru/engine если быть более точным, Yukko!
-
Neter, отрывок из другой темы:
При добавлении записи порежь везде символы "|" и "~".
$string = str_replace(array("|", "~"), "", $string);
Дааа, просто супер изящное и функциональное решение... Без обид.
Neter:
[news=2004-03-19]Helo MOTO[/news]
А чем это отличается от
Helo MOTO
?
Слишком медленно? Честно признаюсь, тестов я не проводил, но expat должен работать достаточно шустро. Или вообще можно юзать БД, как я и предложил позже. В БД есть куча дополнительных весьма полезных возможностей.
Yukko и USE, спасибо за ссыки. Про этот регистр слышу впервые. Сейчас скачаю, поставлю и посмотрю.
-
По поводу регистра: посмотрел я на него, мне не понравился.
Есть любопытные идеи, но в целом ничего особенного.
Внешне выглядит нормально, но код достаточно грязный, нету единого стиля кодирования. Не говоря уже о невалидном HTML\'е.
Что касается формата хранения данных, то он является какой-то пародией на XML.
ИМХО, такой подход можно назвать выгодным только в том случае, если ключевым фактором работы системы является производительность. Да и то не факт, что этот самописный формат работает быстрее, чем парсин XML при помощи expat.
А если правильно организовать кэширование и не парсить XML при каждом запросе, а обновлять кэш только в момент обновления контента - тогда вообще все плюсы самописных форматов сводятся на нет.
-
FreeSpace:
такой подход можно назвать выгодным только в том случае, если ключевым фактором работы системы является производительность
что-то я не догоняю какие такие ключевые факторы более важные чем производительность?
насчет грязного кода - дык регистр это ж в принципе плод спектатора, который к программированию имеет весьма косвенное отношение.
насчет валидного хтмлыля - я что-то не очень понимаю, если ю он выдавал валидный - это какое отношение к формату хранения данных бы имело?
я лично устраняюсь от дальнейшего обсуждения, потому как мое "ИМХО", что гостевухи с субд на бэкенде это изврат. вот такое вот у меня ИМХО.
[off]ИМХО это вообще волшебное слово. можно им прикрываясь безаппеляционно о чем-то утверждать. а вы тут ипитесь - приводите мне примеры и доказывайте обратное. но вот у меня же такое имхо[/off]
-
AliMamed:
это какое отношение к формату хранения данных бы имело?
К формату хранения данных - никакого. Я просто высказал своё мнение о системе в целом.
Да, ты полностью прав, я часто использую аббревиатуру "ИМХО" в своих сообщениях. Но это означает лишь то, что я высказываю собственное мнение, а не то, что каждый должен считать своим долгом убедить меня в своей правоте. Вместе с этим "ИМХО" я привожу какие-никакие, но аргументы. А вот
AliMamed:
гостевухи с субд на бэкенде это изврат
- это не аргумент.
Кстати, изначально речь шла о новостной ленте, а не о гостевухе.
Конечно же, такие вещи как поиск в гостевухе не нужны...
-
Молодые люди, не обладающие абстрактным мышлением.
К вашему сведению, столь сильно разводимые вами в разные стороны веб-приложения, на самом деле не имеют между собой НИКАКОЙ принципиальной разницы. Вообще.
90% скриптов сделаны по принципу гостевой книги.
Так что, вы уж меня извините, но все это детский лепет.
FreeSpace
Вообще-то, я тебя из той темы удалил только для того, чтобы ты беднягу, который еле-еле до пхп дополз, не грузил хмлем.
Преимущества той или иной системы хранения - это, конечно, круто, но будте, пожалуйста, адекватны в своих ответах.
А уж твои - так вообще образец логики. В кавычках.
замена палки на хтмл эквивалент - это, по-твоему, просто непреодолимое препятствие.
А что недо делать хтмлспециалчарс, который понадобится для хранения в хмл - это, типа, ты просто забыл сказать, да?
У вас, ребята, что-то явно нехорошее с логикой. Как-то надо подтянуть, что ли, а?
-
AliMamed, к чему тут регистр, кстати - я так и не понял.
-
RomikChef
А он весь на обычных текстовых файлах.
-
RomikChef это как раз яркий пример цмски "по принципу гостевой книги", написанный на коленке по большому счету.
-
AliMamed:
на коленке
потому что без четкой структуры и плана работ?
-
USE
нет
потому что тока для себя-любимого
у меня самого была такая plain/text байда
похоронил
-
AliMamed
зря ты его приплел.
не по теме.
FreeSpace
запомни.
хранить данные в хмл - глупость.
Оформлять, транспортировать - сколько угодно.
А хранить - не надо.
-
RomikChef:
хранить данные в хмл - глупость.
[off] на самом деле хранение данных небольшого объема в XML - вполне нормально. И иногда практикуется например среди java-программистов. [/off]
-
Похоже я действительно недостаточно чётко выражаю свои мысли.
Буду исправляться.
Я не выступал конкретно за хранение данных в XML! Я выступал и выступаю против хранения данных в самописных форматах, которые тяжело поддерживать и которые не обеспечивают хотя бы минимальных удобств работы с данными без серьёзных потерь в производительности.
Вот мои мысли по этому поводу:
1. Если человек не хочет / не может купить себе нормальный хостинг с поддержкой MySQL или любой другой БД, то
1.1. На небольшом проекте может использовать XML для хранения данных. При небольшом количестве посещений и небольшом размере XML-файлов я уверен, что проблем с производительностью не будет. Если проект внезапно вырастит в что-то бОльшее, чем маленькая домашняя страница, найти деньги на нормальный хостинг проблем не составит. Проблем с конвертацией существующей базы из XML в любую SQL-СУБД не возникнет.
1.2. Если есть возможность и опыт, можно использовать SQLite или вообще какую-нибудь нереляционную СУБД, которую поддерживает хостер. Хотя порой это не намного лучше имплоудов/эксплоудов.
2. Если хостинг нормальный, использовать MySQL и не мучаться.
Мои аргументы?
Я не согласен с Ромиком в том, что все проекты являются продвинутыми гостевухами. Точнее согласен, но не полностью. Как я уже говорил, в гостевухе функция поиска не нужна. Сортировка там тоже идёт только в одном порядке. А вот с новостями уже иначе - поиск совсем бы не помешал. Конечно, сортировка в новостях тоже идёт только в одном направлении, но всё же - подумайте, как можно без извратов реализовать это в своём самописном формате из исплоудов/эксплоудов? Вот после этого и рождаются бессмысленные темы типа "как мне отсортировать массив по второму столбику" (автор, без обид). Используйте стандартизированные форматы хранения данных, у которых есть достаточная инструментальная база и не морочьте голову сами себе.
-
FreeSpace
не каждый хостинг, неподдерживающий mysql дает доступ к XML (expat, domxml, sablotron).
В этом плане самописные форматы основаные на текстовых файлах более универсальны с точки зрения переноса на другой хостинг
-
RomikChef:
90% скриптов сделаны по принципу гостевой книги
FreeSpace:
Я не согласен с Ромиком в том, что все проекты являются продвинутыми гостевухами
с кем-с кем ты не согласен?
FreeSpace:
Я выступал и выступаю против хранения данных в самописных форматах
а а против преподавания таблицы умножения в младших классах тебе, случаем, не приходило в голову повыступать?
А тебе не приходило в голову, что понять прелесть хмл, базы, понять ПРИНЦИПЫ, на которых они работают, можно только попробовав ручками?
А тебе не приходило в голову, что юникс 30 лет работает с плайн текст файлами и ничего - жив-здоров, процветает. Не загнулся без богоспасаемого формата.
А тебе не приходило в голову, что когда появится новый формат, ты точно так же будешь всех агитировать фразами "! Я выступал и выступаю против хранения данных в устаревших и неудобных форматах"?
-
Макс:
не каждый хостинг, неподдерживающий mysql дает доступ к XML (expat, domxml, sablotron).
Согласен. Слона-то я и не заметил...
Таким образом, все мои аргументы по поводу XML можно отправлять прямиком в унитаз.
Ну что-ж, выход один - писать XML-парсер на php самостоятельно... Шутка :)
Рома, прошу прощения, фразу про гостевуху поначалу неправильно истолковал.
Что касается остального - то да, ты прав, не набив шишки на самописных форматах нельзя по-настоящему оценить достоинства стандартных.
Что касается юникса и плайн текста - я не знаком с форматами данных, которые использовались последние 30 лет в юниксе, но что-то подсказывает мне, что они работали не на имплоудах с эксплоудами :rolleyes:
А по поводу новых форматов - вот тут ты попал в яблочко. Это действительно моя слабость - как можно скорее пробовать всё новое. И в такие моменты я бываю достаточно категоричен по отношению к хоть мало-мальски морально устаревшим вещам. Но в данном случае я говорил не о новых форматах, а о стандартизированных. XML был разработан ещё в 1996 году, а SQL - вообще старенький дедушка :), даты даже не припомню, но одно название чего стоит - SQL-92...
Учитывая все ваши аргументы, меняю своё мнение - самописные форматы годятся в двух случаях... нет, наверное даже в трёх:
1. Хроническое отсутствие финансирования
2. Для образовательных целей
3. В некоторых проектах, где производительность является решаюшим фактором.
Кстати, к слову о новых технологиях!
Первого релиз кандидата пятого пыха уже все скачали? :)
-
FreeSpace:
не на имплоудах с эксплоудами
считай их частным случаем регулярок.
работа со стоковыми файлами и разделителями в пхп проста для примитивности. именно под нее была сделана file()
ну что уж прямо так гнать.
хмл - хороший инструмент.Только применять его нужно на месте.
для гостевой - это из пушки по воробьям.
вот недавно человек предложил хранить структуру форумов в хмл.
прекрасное решение!
вместо того, чтобы париться со связанными таблицами, полями для сортировки и так далее - первая страница форума описывается хмл схемой.
очень удобно.
вот оно тут на месте.
описание СТРУКТУРЫ данных. когда данных немного, но они сложные. или для транспорта.
я так думаю.
-
Кстати, тут на другом формуе напомнили.
если так уж хочется заранее стркутурированные данные - в пхп есть великолепный сериалайз.
никакого парсинга
никаких геморроев.
две функции и все данные в готовом к использованию виде.
правда, лично я против сериазлайза
-
Макс
Макс:
на самом деле хранение данных небольшого объема в XML - вполне нормально. И иногда практикуется например среди java-программистов.
более того. теперь будет активно распространятся вместе с .НЕТ
и даже в .НЕТ заменит конфигурационные .инф файлы
FreeSpace:
1. Хроническое отсутствие финансирования
2. Для образовательных целей
это случай 90% посетителей вопрошающих на этом форуме.
FreeSpace:
3. В некоторых проектах, где производительность является решаюшим фактором.
я все таки хочу понять для себя какие еще факторы могут быть важнее производительности и в каких случаях. для меня это невероятно, либо мы по-разному понимаем это слово (без всякой иронии)
-
AliMamed
простой пример.
приложение на ассемблере, или даже на Цэ, вкомпиленное, как модуль апача, убдет работать на порядок производительнее, чем скрипт на пыхе.
отчего ты не пишешь на ассемблере? ведь производительность - главное
-
RomikChef
Али же попросил без иронии :) а это значит, что случаи реализации вебприложения на языке ассемблер можно не трогать, а написание вебприложений на С можно оставить на усмотрение программиста, если ему не хватает скорости выполнения на РНР, то пусть переписывает на С.
-
RomikChef:
отчего ты не пишешь на ассемблере? ведь производительность - главное
это смотря что производительностью назвать. если ты имел в виду только показатели самого приложения, то я имел в виду в целом - и самого приложения и разрабочика
Производительность - показатель среднего объема произведенной товарной продукции на единицу затраченных ресурсов. (http://encycl.yandex.ru/cgi-bin/art.pl?art=glossary/1833/183_3133.HTM&encpage=glossary&mrkp=/yandbtm7%3Fq%3D-1593736143%26p%3D0%26g%3D0%26d%3D0%26ag%3Denc_abc%26tg%3D1%26p0%3D0%26q0%3D2122671664%26d0%3D0%26script%3D/yandpage%253F)
поэтому если я буду "писать на ассемблере" я затрачу больше ресурсов - соответственно общая производительность снижается.
мы все таки не готовые коробочные какие-то продукты обсуждаем, а скорее средства разработки
-
AliMamed:
не готовые коробочные какие-то продукты обсуждаем
кстати, как ты любишь замечать - здесь это оффтопик:abuse:
=)))
-
Говоря о производительности, в данном случае я тоже имел в виду лишь скорость выполнения скрипта. Скорость его написания, удобство эксплуатации и простота обслуживания - это немного другая (но не менее важная) тема.
Да и если подумать, на моё утверждение по поводу производительности нужно наложить жесткие ограничения. Я говорю о всё том же поиске и сортировке, которые при использовании самописных форматов будут работать на порядок медленнее (если их реализовать в php-коде, а не в виде экстеншена и т.д.).
-
AliMamed
ну вот, ты сам себе на этот вопрос и ответил.