Лучший отвечающий
Какие могут быть удобные и быстрые варианты хранения меню для сайта?

Вопрос
-
Всем здравствуйте!
У меня возник вот такой вопрос. Делаю меню для портала, изначально была мысль, хранить его в БД. В такой вот таблице:
ID
NodeID
NodeName
Достаточно удобно, динамично, нет ограничений по вложенности. К статьям можно цеплять NodeID для определения их категории.
Но с другой стороны, не будет ли этот вариант меню "тяжел" в плане выборки из БД? Ведь по сути при его построение мы переберем на каждый ID все NodeID, можно конечно добавить хранение пути, но тогда это снимет нагрузку с SQL и добавит ей в парсер C# ну или (SQL :)). Вот я и хочу спросить у гуру, использовать такой вариант хранения меню или есть какие-то более "новые" варианты?
З.Ы. Извините, если вопрос задан несколько сумбурно :(
22 февраля 2011 г. 12:30
Ответы
-
Обычно, категории на сайте меняются редко, поэтому их зачастую кэшируют в памяти для уменьшения количества запросов к БД. А если еще используется Microsoft SQL Server 2005 или выше, то при помощи SqlCacheDependency можно получать уведомления об обновлении списка категорий непосредственно в момент обновления.
По структуре таблицы — я в большинстве случаев использую такую же (идентификатор меню, идентификатор родительского меню, наименование).
- Помечено в качестве ответа Mastekor 22 февраля 2011 г. 13:02
- Изменено Алексей Митев 22 февраля 2011 г. 13:07 уточнение про версию MSSQL
22 февраля 2011 г. 12:39 -
Хм, то есть я так понял, что при изменении меню, первая загрузка (по сути первый пользователь) страницы создаст кэш, а вторая будет уже дергать кэш.
Да, все верно
Я не силен в SQL. У него время жизни есть? Вернее, что определяет время жизни кэша, кроме изменения данных в таблице?
т.е. перезагрузка, бэкап, шринк ДБ и т.п.
Посмотрите объект Cache . Его функциональность и область видимости похожа на коллекцию Application (в плане хранения глобальных данных), только в Cache есть еще возможность задавать политику устаревания данных. Для устаревших данных кэш будет обновляться автоматически при следующем запросе к элементу кэша.
- Помечено в качестве ответа Mastekor 22 февраля 2011 г. 13:03
22 февраля 2011 г. 12:59
Все ответы
-
Обычно, категории на сайте меняются редко, поэтому их зачастую кэшируют в памяти для уменьшения количества запросов к БД. А если еще используется Microsoft SQL Server 2005 или выше, то при помощи SqlCacheDependency можно получать уведомления об обновлении списка категорий непосредственно в момент обновления.
По структуре таблицы — я в большинстве случаев использую такую же (идентификатор меню, идентификатор родительского меню, наименование).
- Помечено в качестве ответа Mastekor 22 февраля 2011 г. 13:02
- Изменено Алексей Митев 22 февраля 2011 г. 13:07 уточнение про версию MSSQL
22 февраля 2011 г. 12:39 -
Хм, то есть я так понял, что при изменении меню, первая загрузка (по сути первый пользователь) страницы создаст кэш, а вторая будет уже дергать кэш.
Я не силен в SQL. У него время жизни есть? Вернее, что определяет время жизни кэша, кроме изменения данных в таблице?
т.е. перезагрузка, бэкап, шринк ДБ и т.п.
22 февраля 2011 г. 12:51 -
Хм, то есть я так понял, что при изменении меню, первая загрузка (по сути первый пользователь) страницы создаст кэш, а вторая будет уже дергать кэш.
Да, все верно
Я не силен в SQL. У него время жизни есть? Вернее, что определяет время жизни кэша, кроме изменения данных в таблице?
т.е. перезагрузка, бэкап, шринк ДБ и т.п.
Посмотрите объект Cache . Его функциональность и область видимости похожа на коллекцию Application (в плане хранения глобальных данных), только в Cache есть еще возможность задавать политику устаревания данных. Для устаревших данных кэш будет обновляться автоматически при следующем запросе к элементу кэша.
- Помечено в качестве ответа Mastekor 22 февраля 2011 г. 13:03
22 февраля 2011 г. 12:59 -
Все ясно. Спасибо22 февраля 2011 г. 13:03