Организации базы данных (PHP)

[dr.Chas]

Всем здраствуйте. Вот вылезла проблема, вприципе варианты у меня есть разные, но что то мне кажется это не правильно. Да и думаю это не велосипед, так что прошу совета.

И так ситуация такая. (смотрим вложение ниже):

Имеется сайт. На нём меню которое будет создаваться динамически. В нём например 3 категории:
Новости
Статьи
Меню (с вложением)

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

p.s.: мб не очень понятно изложил, спрашивайте, если что не понятно.

[Виталий Желтяков]

Здесь правильное решение таится в том как Вы будете организовывать формирования меню. Если Вы формируете меню всё сразу, то лучше использовать 1 таблицу. Если подменю формируется только при нажатии, то две. Это связано с тем, что каждый fetch таблицы требует времени.
Если честно, по-моему, ваша идея с динамическим меню, берущимся из базы, довольно плоха, т.к. очень ресурсоёмка. Проще использовать подключаемый include-ом php-фаил с настройками меню в удобной форме.

[dr.Chas]

Сообщение от Виталий Желтяков

Здесь правильное решение таится в том как Вы будете организовывать формирования меню. Если Вы формируете меню всё сразу, то лучше использовать 1 таблицу. Если подменю формируется только при нажатии, то две. Это связано с тем, что каждый fetch таблицы требует времени.
Если честно, по-моему, ваша идея с динамическим меню, берущимся из базы, довольно плоха, т.к. очень ресурсоёмка. Проще использовать подключаемый include-ом php-фаил с настройками меню в удобной форме.

Да, да, вы меня поняли И я о том же, что сайт нагружать, лишними запросами идея не самая лучшая, тем более в две таблицы. Я вприципе понял что вы имеете ввиду, есть пример такой реализации? Я просто на пхп ток перешёл. Написать то я могу и без примера, но опять будет велосипед

[add]
Попробывал, что-то как то не очень получается. Мб ещё примеры есть?

[Andkorol]

Сообщение от Виталий Желтяков

Если честно, по-моему, ваша идея с динамическим меню, берущимся из базы, довольно плоха, т.к. очень ресурсоёмка.

Вас послушать - так вообще пора переходить на статические страницы - ну их,эти Базы Данных!!!...
Кто вообще придумал хранить информацию в этих жутких,ресурсоёмких Базах...???
ЧЕМ запрос десятка текстовых строк так уж перегрузит сервер????

Сообщение от Виталий Желтяков

Проще использовать подключаемый include-ом php-фаил с настройками меню в удобной форме.

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

dr.Chas - если это будет динамическое меню(т.е. количество пунктов или информация в пунктах может изменяться),то делайте его при помощи БД - и не парьтесь.
Это упростит создание и редактирование пунктов вашего меню,а так же сэкономит вам кучу времени при работе с таким меню....
Поверьте,оптимизация запросов к БД не настолько сурова,что прям уж и меню нельзя сделать...

[dr.Chas]

Сообщение от Andkorol

dr.Chas - если это будет динамическое меню(т.е. количество пунктов или информация в пунктах может изменяться),то делайте его при помощи БД - и не парьтесь.
Это упростит создание и редактирование пунктов вашего меню,а так же сэкономит вам кучу времени при работе с таким меню....
Поверьте,оптимизация запросов к БД не настолько сурова,что прям уж и меню нельзя сделать...

Ну по началу так и собирался. Но выходят почти две одинаковые таблицы, что как то не так. Как обычно такое делается?

[mv28jam]

Учите теорию и не будет таких вопросов!
ОСНОВЫ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

[dr.Chas]

Сообщение от mv28jam

Учите теорию и не будет таких вопросов!
ОСНОВЫ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

Супер ответ, ты мне очень помог. Молодец возьми с полки пирожок. Ты бы меня ещё в поиск отправил... Если ты её подучил, мб что-то посоветуешь?

[mv28jam]

Сообщение от dr.Chas

Супер ответ, ты мне очень помог. Молодец возьми с полки пирожок. Ты бы меня ещё в поиск отправил... Если ты её подучил, мб что-то посоветуешь?

Я дал Вам правильный, дельный и нужный лично для Вас совет. Прежде чем хамски отвечать надо подумать, почему Вам дают такой совет.

Но раз свой мозг вы тренировать не хотите, из жалости к сирым не "подучившим" подскажу. В таблице categories надо ввести поле parent, в котором будет находиться id родительской категории, если это подкатегория или false если это родительская категория. Используя такую схему, можно организовать любую глубину вложенности.

[dr.Chas]

Сообщение от mv28jam

Я дал Вам правильный, дельный и нужный лично для Вас совет. Прежде чем хамски отвечать надо подумать, почему Вам дают такой совет.

Но раз свой мозг вы тренировать не хотите, из жалости к сирым не "подучившим" подскажу. В таблице categories надо ввести поле parent, в котором будет находиться id родительской категории, если это подкатегория или false если это родительская категория. Используя такую схему, можно организовать любую глубину вложенности.

Во-первых, разберём твой дельный совет:
Когда человек обращается на форум спрашивая, он ждёт не обтекаемых фраз в стиле: "прочитай учебник по php", "выучи всю теорию по бд", а нормально толчка в правильном направлении. Возможно примера или т.п. Давай на все темы на форумах, отвечать в стиле: "Вам нужно почитать учебник по делфи", "А тут вам надо подучить теорию". Зачем тогда форум? (ты видать забыл для чего существуют такие форумы, хотя для тебя он наверно и существует для того чтобы самоутвердиться)

Что же дал твой дельный совет? Он вместо толчка в правильном направлении предложил почитать пару учебников. Потом же ты написал нормально, а почему сразу так не написать?

Теперь не большая выписка из правил, которые я так понял ты не читал, а там есть довольно интересная информация, как раз для тебя:

Рекомендации:
Не публикуйте сообщения "читайте книгу", указывайте в какой книге, а лучше с ссылкой.
Не стоит отправлять в поиск, не хотите отвечать пройдите мимо. Хотите помочь, пишите конкретный ответ.

Как раз такие рекомендации правильные. Не стоит лишний раз флудить в темах набивая сообщения для чего? (а иначе я не могу объяснить твой дельный совет)

Во-вторых, я на личности не переходил, да я поблагодарил тебя в сатирическом стиле за твой "дельный" совет, но это не повод переходить на личности.

p.s.: без тебя и так разобрался.

[Виталий Желтяков]

Здесь правильное решение таится в том как Вы будете организовывать формирования меню. Если Вы формируете меню всё сразу, то лучше использовать 1 таблицу. Если подменю формируется только при нажатии, то две. Это связано с тем, что каждый fetch таблицы требует времени.

Я уже дал ответ как надо организовать БД. Вы что все отвлеклись на обсуждение скорости работы.

Вас послушать - так вообще пора переходить на статические страницы - ну их,эти Базы Данных!!!...
Кто вообще придумал хранить информацию в этих жутких,ресурсоёмких Базах...???
ЧЕМ запрос десятка текстовых строк так уж перегрузит сервер????

Сразу видно что Andkorol пишет сайты с максимумом посещений 30 человек в день и не представляет, как дорого обходиться работа с БД при более 2000 человек в день.