while( $arr=mysql_fetch_array($res) )
{
echo 'Имя: '.$arr['name'].'<br><br>';
echo '<br> <a href="?action=edit&type='.$type.'&id='.$arr[id].'">EDIT </a>
<a href="?action=delete&id='.$arr[id].'" > DELETE </a> <br>';
}
Концепция работы сайта. Размышления. [PHP]
Привет, сообщество!
Вобщем, сел писать сайт. Раньше было всё тупо до безобразия - набор html или php файлов, и ссылки на сайте указывали прямо на эти файлы.
Однако, захотелось динамики, "отвязки" от файлов и более грамотной организации. Только вот пока что я в раздумьях как это дело организовать.
Расскажу что Уже написано.
Вобщем, при создании страницы (будь то страница со статикой или с php-кодом) я указываю ей её идентификатор (page_id) и сохраняю страницу в базе.
Допустим есть ссылка: мой_сайт.com/?page_id=news . При переходе по ссылке делается запрос в БД, и вытаскивается содержимое страницы.
Структура в базе примерно такая:
id | ... | page_id | page_content
=========================
1 | ... | news | include("pages.php"); news_page(); //eval
2 | ... | about| Текст о нас. Просто статика.
........
Как оцениваете такое решение и какие ещё есть вариантЫ?
Вобщем, сел писать сайт. Раньше было всё тупо до безобразия - набор html или php файлов, и ссылки на сайте указывали прямо на эти файлы.
Однако, захотелось динамики, "отвязки" от файлов и более грамотной организации. Только вот пока что я в раздумьях как это дело организовать.
Расскажу что Уже написано.
Вобщем, при создании страницы (будь то страница со статикой или с php-кодом) я указываю ей её идентификатор (page_id) и сохраняю страницу в базе.
Допустим есть ссылка: мой_сайт.com/?page_id=news . При переходе по ссылке делается запрос в БД, и вытаскивается содержимое страницы.
Структура в базе примерно такая:
id | ... | page_id | page_content
=========================
1 | ... | news | include("pages.php"); news_page(); //eval
2 | ... | about| Текст о нас. Просто статика.
........
Как оцениваете такое решение и какие ещё есть вариантЫ?
А картинки тоже в базе храните?
По моему, стоит посмотреть движки некоторых CMS с открытым исходным кодом, а потом ваять такие чудеса... :)
По моему, стоит посмотреть движки некоторых CMS с открытым исходным кодом, а потом ваять такие чудеса... :)
Цитата: wAngel
А картинки тоже в базе храните?
По моему, стоит посмотреть движки некоторых CMS с открытым исходным кодом, а потом ваять такие чудеса... :)
По моему, стоит посмотреть движки некоторых CMS с открытым исходным кодом, а потом ваять такие чудеса... :)
Ну почему-же в базе. В базе только текст, в т.ч. ссылки на картинки, хранящиеся на сервере.
Я понимаю что, возможно, этот метод глуп/не правилен/и т.д. Но потому-то я и написал сюда, что-бы услышать ваши мнения об этом, какие-то мысли по поводу улучшения либо может вообще не в том направлении двигаюсь.
Метод не то чтобы глуп... Но немного странен что ли... Зачем вам идентификатор текстовый? Почему не подходит число? Вы уверены что правильно проверяете этот самый идентификатор прежде чем в базе по нему поиск проводить?
RussianSpy: ну, это собственно не архиважный момент. идентификатор можно сделать числом (что-бы само и генерировалось), кстати так и сделаю наверное.
В данный момент интересует сама концепция хранения страниц (как статичных так и тех что выполняют какой-то код) в БД.
В данный момент интересует сама концепция хранения страниц (как статичных так и тех что выполняют какой-то код) в БД.
Ну на мой взгляд ничего необычного нет
простенький скрипт, минимум логики, линейная структура
что вас смущает?
простенький скрипт, минимум логики, линейная структура
что вас смущает?
Ну, смущать-то ничего особо не смущает, за исключением того что каждый раз когда запрашивается та или иная страница, происходит запрос в БД.
Да и вобщем хотелост узнать, какие ещё принципы хранения и вывода страниц бывают.
Да и вобщем хотелост узнать, какие ещё принципы хранения и вывода страниц бывают.
я тебе уже в аське говорил - в этом ничего старшного нету, но лучше предусмотреть возможность кэширования, чтобы не дергать БД при каждом запросе. и еще... судя по всему - нужно сделать нормализацию БД.
Для простого статического текста лучше ложить в файлы(если цмс пишеться не под один мелкий проект а планируеться ее использовать в дальнейшем), , я в свое время сделал глупость что ложил в базу статические хтмл - а вот щас уже времени(или желания) исправлять цмс нету, так что этот пунк лучше реализовывать сразу - т.е делать гибридку
Цитата: Fenyx
Для простого статического текста лучше ложить в файлы(если цмс пишеться не под один мелкий проект а планируеться ее использовать в дальнейшем), , я в свое время сделал глупость что ложил в базу статические хтмл - а вот щас уже времени(или желания) исправлять цмс нету, так что этот пунк лучше реализовывать сразу - т.е делать гибридку
Складывать нужно в БД, но при это написать систему кэширования страниц. Если собираешься писать более-менее осмысленную систему - файлы не дадут ничего кроме сложностей и неудоства.
Цитата: RussianSpy
Складывать нужно в БД, но при это написать систему кэширования страниц. Если собираешься писать более-менее осмысленную систему - файлы не дадут ничего кроме сложностей и неудоства.
а смысл ложить в бд? кроме нагрузки и лишних вызовов функций - ничего не дает - кеширование - то же ложение в файлы. Как раз я бы щаз реализовывал файловый подход к редко изменяемым записям, тогда и кеширывания не нужно, чтение файла быстрее скул запроса, а траблы и путаница ))) один клас пишеться и все
Цитата: Fenyx
а смысл ложить в бд? кроме нагрузки и лишних вызовов функций - ничего не дает - кеширование - то же ложение в файлы. Как раз я бы щаз реализовывал файловый подход к редко изменяемым записям, тогда и кеширывания не нужно, чтение файла быстрее скул запроса, а траблы и путаница ))) один клас пишеться и все
Ну вот когда начнешь писать что-то более серьезное, чем у автора топика - сам поймешь.
абсолютно солидарен с Fenyx
в базе текст хранить не стоит
2patison рекомендую взглянуть в сторону bitrix
очень удобный смешеный стиль
минимальная нагрузка
простая и понятная структура
в базе текст хранить не стоит
2patison рекомендую взглянуть в сторону bitrix
очень удобный смешеный стиль
минимальная нагрузка
простая и понятная структура
По мне - так все тексты хранить в БД. А уже статику кэшировать в файлы, как и говорит RussianSpy. По крайней мере, намного легче делать бэкап и переносимость данных и не нагружать код выборкой чтения то оттуда, то оттуда.
ЗЫ: в кэш соответсвенно пихать страницу с уже вставленными заменами BB-кодов и прочего.
ЗЫ: в кэш соответсвенно пихать страницу с уже вставленными заменами BB-кодов и прочего.
Цитата: UAS
По мне - так все тексты хранить в БД. А уже статику кэшировать в файлы, как и говорит RussianSpy. По крайней мере, намного легче делать бэкап и переносимость данных и не нагружать код выборкой чтения то оттуда, то оттуда.
ЗЫ: в кэш соответсвенно пихать страницу с уже вставленными заменами BB-кодов и прочего.
ЗЫ: в кэш соответсвенно пихать страницу с уже вставленными заменами BB-кодов и прочего.
В этом случае теряеться гибкость работы с переменными дизайна - а если банер нужно изменить который сквозняком идет? а ссылка в шаблон новая добавилась? да хоть взять тот же рендомный вывод чего то.... все перекешировать? о_О
Согласен что полный кеш быстрее, но мороки с ним на порядок больше
Цитата: RussianSpy
Ну вот когда начнешь писать что-то более серьезное, чем у автора топика - сам поймешь.
Эхь )) как мне нравицца твоя самоуверенность )) аргументируй... ))
Ребят, КЭШ нужен, на мой взгляд, только когда очень большая посещаемость. А когда стоит необходимость делать подобный проект, можно и кэшировать раз в сутки. Это-ж не так проблематично. или я не прав?
+ Хранение в базе удобней тем, что если потребуется делать Многоязычность - проще будет оперировать данными (т.е. немного переделать структуру базы (таблицы), и добавить "пару символов" в запрос).
+ Хранение в базе удобней тем, что если потребуется делать Многоязычность - проще будет оперировать данными (т.е. немного переделать структуру базы (таблицы), и добавить "пару символов" в запрос).
Fenyx, ну так добавилась ссылка - перекомпилить шаблон и все) Проблем-то) С баннерами тоже) Хотя с баннером не понял. Т.е. динамик баннер в статик странице? ну тут уже другие подходы.
Но все равно останусь на своем - в БД инфа, в файлах кэш, дизайн и собственно сам код
Но все равно останусь на своем - в БД инфа, в файлах кэш, дизайн и собственно сам код
Ну шаблоны можно и в виде файла хранить, а можно и в БД - это как раз не принципиально тк их вряд ли будут сотни и тысячи.
Если ты такой любитель файлов - зачем тебе вообще БД? Храни все в файлах. Возврат в 90е годы невеян ностальгией?
Если ты такой любитель файлов - зачем тебе вообще БД? Храни все в файлах. Возврат в 90е годы невеян ностальгией?
Цитата: RussianSpy
Ну шаблоны можно и в виде файла хранить, а можно и в БД - это как раз не принципиально тк их вряд ли будут сотни и тысячи.
Если ты такой любитель файлов - зачем тебе вообще БД? Храни все в файлах. Возврат в 90е годы невеян ностальгией?
Если ты такой любитель файлов - зачем тебе вообще БД? Храни все в файлах. Возврат в 90е годы невеян ностальгией?
Я говорил про тотальный кеш страницы - т.е. то что отдает сервак, а не шаблоны...
Интересно,RussianSpy, ты кричал что сирьезные проекты делал - они полностью все на БД? даже с учетом неплохой реализации постгре...?
И кса по поводу ностальгии - новые проекты поднимаю через гибридку и не жалуюсь - единственный минус что без меня их тяжело будет разобрать, но для работы это + ))
Да
у меня все хранится в БД. Также система обеспечивает кэширование страниц. Однако не все страницы можно кэшировать. Например содержащие приватные данные кэшировать нельзя.
В общем спор ни о чем - делай как тебе хочется. Я же свою позицию выработал на основе 8-летнего опыта работы.
Успехов
у меня все хранится в БД. Также система обеспечивает кэширование страниц. Однако не все страницы можно кэшировать. Например содержащие приватные данные кэшировать нельзя.
В общем спор ни о чем - делай как тебе хочется. Я же свою позицию выработал на основе 8-летнего опыта работы.
Успехов
Цитата: RussianSpy
Да
у меня все хранится в БД. Также система обеспечивает кэширование страниц. Однако не все страницы можно кэшировать. Например содержащие приватные данные кэшировать нельзя.
В общем спор ни о чем - делай как тебе хочется. Я же свою позицию выработал на основе 8-летнего опыта работы.
Успехов
у меня все хранится в БД. Также система обеспечивает кэширование страниц. Однако не все страницы можно кэшировать. Например содержащие приватные данные кэшировать нельзя.
В общем спор ни о чем - делай как тебе хочется. Я же свою позицию выработал на основе 8-летнего опыта работы.
Успехов
Согласен, холивар не о чем )) прост не употребляй некоторые выражения ;) (кста линейку для измерения "опыта" я уже давно где то потерял (( )
А по проектам - самую высокую производительность ИМХО дает именно грамотно построенная гибридка - т.е база, тригерры, функции базы + файлы - но тут трабла что система не такая гибкая как только база, но более маштабируемая и не всегда зависящая от нагрузки самой базы - что сказываеться на скорости
ЗЫ а вот про кеширование средствами бд - интересно
Ура, Спор окончен, Можно идти дальше. Вобщем, такой вопрос назрел.
Есть АДМИНКА. В ней есть действия кот-ые может производить юзер (заказчик), а есть те которые только главный "админ" сайта (в данном случае - Я). пока что реализовал это дело как две разные админки, но понимаю что это не правильно. Нужно сделать рег юзеров, с разграничением прав. Вот тут-то и вопрос. Как?
Скажем, есть список материалов сайта (новости к примеру):
- новость 1 [edit, delete]
- новость 2 [edit, delete]
....
Напротив каждого материала - действие. Так вот. как сделать правильней, что-б после "прочтения" из БД прав, эти действия отображались/не_отображались?
зы ессна логический оператор (ИФ) само собой не рассматривается =)
Есть АДМИНКА. В ней есть действия кот-ые может производить юзер (заказчик), а есть те которые только главный "админ" сайта (в данном случае - Я). пока что реализовал это дело как две разные админки, но понимаю что это не правильно. Нужно сделать рег юзеров, с разграничением прав. Вот тут-то и вопрос. Как?
Скажем, есть список материалов сайта (новости к примеру):
- новость 1 [edit, delete]
- новость 2 [edit, delete]
....
Напротив каждого материала - действие. Так вот. как сделать правильней, что-б после "прочтения" из БД прав, эти действия отображались/не_отображались?
зы ессна логический оператор (ИФ) само собой не рассматривается =)
Да вариантов на эту тему может быть много. (по поводу разграничения прав)
Допустим есть отдельная таблица в БД, в которой есть поля: ид пользователя(ну или логин), доступная функция и статус записи .
Делается выборка на список доступных функций конкретному пользователю, и собственно все. В соответствии с этими данными оперируешь.
(Ровно так я сделал у себя, пока что)
Допустим есть отдельная таблица в БД, в которой есть поля: ид пользователя(ну или логин), доступная функция и статус записи .
Делается выборка на список доступных функций конкретному пользователю, и собственно все. В соответствии с этими данными оперируешь.
(Ровно так я сделал у себя, пока что)
bobik02: мне не совсем понятно как выводить/не показывать разрешённые/запрещённые действия. В данный момент я делаю так, например:
Думаю идея яснА. Отображается Имя материала и две ссылки EDIT | DELETE. Вот как-бы показывать/не показывать их в зависимости от того какие права у юзера?
Код:
Думаю идея яснА. Отображается Имя материала и две ссылки EDIT | DELETE. Вот как-бы показывать/не показывать их в зависимости от того какие права у юзера?
Ну вот тебе примитивный пример:
Допустим есть в БД:
Таблица UserList поля: id, name ... т.к.
1 test
2 bobik
Таблица FunctionList поля: id, name ...
1 edit
2 delete
И таблица AccessUserList, поля: iduser, idfunction ...
2 1
2 2
1 1
т.е. у юзера бобик доступна ф-ция редактировать и удалить, а у теста только редактировать.
При генерации функций для конкретного пользователя, делается выборка, и в соответствии с правами дается полномочия.
Допустим есть в БД:
Таблица UserList поля: id, name ... т.к.
1 test
2 bobik
Таблица FunctionList поля: id, name ...
1 edit
2 delete
И таблица AccessUserList, поля: iduser, idfunction ...
2 1
2 2
1 1
т.е. у юзера бобик доступна ф-ция редактировать и удалить, а у теста только редактировать.
При генерации функций для конкретного пользователя, делается выборка, и в соответствии с правами дается полномочия.
Это-то понятно =) Не понятно пока другое - как организовать именно вывод разрешённых действий. Т.е. что я имею ввиду:
но это чисто так, в качестве примера. глупо по-моему IFами пробегать.
Код:
if( юзер может редактировать )
echo '<a href="?a=edit">EDIT</a>';
echo '<a href="?a=edit">EDIT</a>';
но это чисто так, в качестве примера. глупо по-моему IFами пробегать.
Цитата: patison
Это-то понятно =) Не понятно пока другое - как организовать именно вывод разрешённых действий. Т.е. что я имею ввиду:
но это чисто так, в качестве примера. глупо по-моему IFами пробегать.
Код:
if( юзер может редактировать )
echo '<a href="?a=edit">EDIT</a>';
echo '<a href="?a=edit">EDIT</a>';
но это чисто так, в качестве примера. глупо по-моему IFами пробегать.
Реализуй класс который инклудиться в основной файл обработчик, а в нем куки сессии и тд.
В пхп 5 есть замечательная возможность __constract & __destract
Цитата: patison
глупо по-моему IFами пробегать.
Ничего глупого.
Цитата: Fenyx
Реализуй класс который инклудиться в основной файл обработчик, а в нем куки сессии и тд.
В пхп 5 есть замечательная возможность __constract & __destract
В пхп 5 есть замечательная возможность __constract & __destract
__construct
__destruct
сначала читаем что написали - потом нажимаем кнопку "Ответить"
Fenyx: чё-то я не совсем понимаю как это относится к вопросу о том показывать/не показывать те или иные ссылки в зависимости от прав. Можно подробнее?
Nixus: разве? именно "глупость" (по мне так) проверки всего подряд ИФами, толкнуло меня на хранение страниц в базе. Можно ведь было делать так примерно:
ИФ(pageid=1)
include(page1.php);
ИФ(pageid=2)
include(page2.php);
Но это помоему верх неразумности, так сказать =)
Nixus: разве? именно "глупость" (по мне так) проверки всего подряд ИФами, толкнуло меня на хранение страниц в базе. Можно ведь было делать так примерно:
ИФ(pageid=1)
include(page1.php);
ИФ(pageid=2)
include(page2.php);
Но это помоему верх неразумности, так сказать =)
patison, тут уж надо уже подумать как красиво сделать(спроектировать) в Вашей ситуации. Включите моск на полную катушку и запаситесь большим колчичеством жидкости и витаминов :D
Я действительно делаю иф-ом, но я применяю в другой ситуации, если(if) конретному пользователю доступная организация Y, то отобразить некоторую информацию. т.е. у меня всего один иф который отображаеться в одном месте, и мне не критично.
Я действительно делаю иф-ом, но я применяю в другой ситуации, если(if) конретному пользователю доступная организация Y, то отобразить некоторую информацию. т.е. у меня всего один иф который отображаеться в одном месте, и мне не критично.
bobik02: хехе, вот именно, что для одного места один ИФ далеко не критичен. Ладно, побежал я в аптеку за витаминами :)))
Ну так вот как раз страницы через if проверять - это идиотизм. А вот ифами проверять права - вполне норм. Ну или хранить все права в БД для каждого юзера, и потом просто написать один раз скрипт, который будет их проверять и выводить. И опять же он будет на if работать. Ну или каждому праву давать свой ID, потом просто вставлять в нужные места на странице эти ID, кот. будут заменяться на пустую строку или на строку с инфой редактирования. Вот и все.
хм, пожалуй вы правы. чтоб особо не мудрить и не усложнять всё, можно заюзать if.
Вот например расскажу как сделал в другом случае. Вобщем надо было создавать мне типы материалов на сайте, и для каждого типа материала форма заполнения будет разная. Например новости имеют поля Дата, Название, Тело. А статья например содержит Название, Краткое описание, Тело. Вот для динамического создания типов материалов я сделал следующее:
Создал ВСЕ возможные поля. При создании типа материала каждое поле обозначил чекбоксом (если отмечено - то поле будет отображатся). И, самое интересное, если стоит галочка, то в БД у данного поля в таблице в колонке visibility прописывается normal, в противном случае - none. И получается что при заполнении, например, новости, впринципе на странице есть ВСЕ возможные поля, но вот только видны те у которых visibility: normal.
Это так, для интересующихся и для критиков :)
Вот например расскажу как сделал в другом случае. Вобщем надо было создавать мне типы материалов на сайте, и для каждого типа материала форма заполнения будет разная. Например новости имеют поля Дата, Название, Тело. А статья например содержит Название, Краткое описание, Тело. Вот для динамического создания типов материалов я сделал следующее:
Создал ВСЕ возможные поля. При создании типа материала каждое поле обозначил чекбоксом (если отмечено - то поле будет отображатся). И, самое интересное, если стоит галочка, то в БД у данного поля в таблице в колонке visibility прописывается normal, в противном случае - none. И получается что при заполнении, например, новости, впринципе на странице есть ВСЕ возможные поля, но вот только видны те у которых visibility: normal.
Это так, для интересующихся и для критиков :)
Цитата: patison
Создал ВСЕ возможные поля. При создании типа материала каждое поле обозначил чекбоксом (если отмечено - то поле будет отображатся). И, самое интересное, если стоит галочка, то в БД у данного поля в таблице в колонке visibility прописывается normal, в противном случае - none. И получается что при заполнении, например, новости, впринципе на странице есть ВСЕ возможные поля, но вот только видны те у которых visibility: normal.
Это так, для интересующихся и для критиков :)
Это так, для интересующихся и для критиков :)
такого извращения я ещё не видел о_0
нафига, извините, хранить поле, размером с минимум в 6 байтов, когда можно его зранить как просто BOOL? Т.е. 1 - отображать, 0 - не отображать. А уже при формировании статьи делать visibility на основе этих 0 и 1
Nixus: никак. я просто привёл пример.
UAS: А я так и сделал с самого начала. только вот дело в том что опять придётся как-то извращаться с условиями или ещё как-то. А так у меня в переменной (visibility) лежит нужное значение (normal или none), которое я сразу вывожу в style="....".
Тем более, лишние 40-50 байт не смертельно. или смертельно?......
После некоторых раздумий, пришёл к тому что вы, товарисч, UAS, правы. Был найден альтернативный выход с использованием BOOL типа для данного вопроса, и значения 0 и 1 в базе =)
Спасибо за наставление :)
UAS: А я так и сделал с самого начала. только вот дело в том что опять придётся как-то извращаться с условиями или ещё как-то. А так у меня в переменной (visibility) лежит нужное значение (normal или none), которое я сразу вывожу в style="....".
Тем более, лишние 40-50 байт не смертельно. или смертельно?......
После некоторых раздумий, пришёл к тому что вы, товарисч, UAS, правы. Был найден альтернативный выход с использованием BOOL типа для данного вопроса, и значения 0 и 1 в базе =)
Спасибо за наставление :)
Цитата:
И получается что при заполнении, например, новости, впринципе на странице есть ВСЕ возможные поля, но вот только видны те у которых visibility: normal.
Смысл вообще выводить поля, которые не должны быть видимы?
patison, ну дык так хоть как правильно =) Вот допустим хотите сделать фильтр по этому свойству. Так поиск по БД в любом случае будет быстрее по BOOL полю, чем по VARCHAR/CHAR. Да и принцип-то какой? Поле работает как флаг. Флаг может быть или нет, т.е. 1 или 0. В принципе вот и все.
А с if'ами проблемы не будет, там делов-то на 2-3 строчки: цикл по этим полям и проверка на 1 или 0. Все в одну строчку спокойно влезает
А с if'ами проблемы не будет, там делов-то на 2-3 строчки: цикл по этим полям и проверка на 1 или 0. Все в одну строчку спокойно влезает
Цитата: patison
Nixus: никак. я просто привёл пример.
Пример чего? Бардака в голове?
if в первом перемере одно из самых адекватных решений, если не самое адекватное.
if во втором примере - самое не адекватное решение.
Или ты принципиальной разницы между этими примерами не видишь?