Я создаю веб-сайт, где все страницы свешиваются на древовидной иерархии, управляемой базой данных.
Все, кроме одного узла, имеют родительский узел. Узлы могут иметь разрешения на чтение на основе ролей. Некоторые узлы могут иметь особые правила (например: не отображать в меню навигации).
Узлы могут представлять собой ссылки на другие узлы (например, ярлык в Windows). Узлы обычно представляют страницы.
Страницы представляют либо содержимое HTML, либо выполнить программирование. Некоторые страницы могут быть корнями поддеревьев (альтернативные мастер-страницы и таблицы стилей).
Пожалуйста, помогите мне настроить мою базу данных узлов в Microsoft SQL Server для использования Linq to SQL.
У меня есть три идеи:
Множество легких столов с почти нулевые поля nullalbe.
Таблица узлов тяжелого веса с большим количеством nullalbe поля.
Лучшее (или худшее) из обоих: много nullalbe внешние ключи для многих легкие столы.
Что, по вашему мнению, лучше всего представляет данные? Что будет проще всего использовать с Linq to SQL?
Как я могу сохранить свои правила целостности данных в базе данных? Как мне лучше всего обеспечить их соблюдение в моем программировании?
Узлы должны быть одним (но не обоими) ссылки или страницы.
Страницы должны быть либо (но не одновременно) HTML, либо кодом.
Ссылки не могут быть корнями, HTML или кодом.
Могу ли я создать поставщик карты сайта ASP.NET с такой структурой? Нужно ли мне?
Обновление: я задал более общий вопрос:
Как лучше всего обрабатывать взаимно-однозначные отношения в SQL?
Связанный вопрос:
Как обеспечить соблюдение правил целостности данных в моей базе данных?
Мое первое впечатление после прочтения вашего сообщения таково, что я бы очень не хотел, чтобы одна технология любой (в данном случае linq) сильно влияла на дизайн схемы базы данных в той степени, в которой вы, кажется, предполагаете.
Я думаю, что ваша схема должна быть примерно такой же, независимо от того, какую технологию вы затем выбрали для создания уровней бизнеса / презентации.
Надеюсь, я вас правильно понял.