none
Какие могут быть удобные и быстрые варианты хранения меню для сайта? RRS feed

  • Вопрос

  • Всем здравствуйте!

    У меня возник вот такой вопрос. Делаю меню для портала, изначально была мысль, хранить его в БД. В такой вот таблице:

    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