Как элегантнее обеспечить ссылочную целостность (MS SQL) | |
---|---|
JS Автор Сообщений: 12264 Откуда: Эстония Дата регистрации: 04.09.2000 |
Есть работающий проект с базой данных структуры Группы -> Категории -> Субкатегори первого уровня -> Субкатегории второго уровня,
в которой ссылочная целостность (RI) обеспечивалась на уровне стандартных процедур самого сервера. Срочно понадобилось увеличить количество подуровней субкатегорий до заранее неизвестного числа - может быть до 10-15 подуровней или просто неизвестное количество вложений. Самое простое решение - убрать все таблицы субкатегорий и создать новую с parentID, childId и таблицу для записей из которой будут браться ключи для parentID и childId. Пока решение по обеспечению RI громоздкое... Что посоветуете? Проблема как всегра одна - в пятницу должен быть уже за границей, а решение хочется найти до отъезда. P.S. Это не магазин, это планирование (причем неграмотное техзадание). ------------------ Knowledge is better than ignorance! Website: juri.foxhelp.eu Исправлено 3 раз(а). Последнее : JS, 13.06.16 09:47 |
Re: Как элегантнее обеспечить ссылочную целостность (MS SQL) | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Не понял зачем нужна отдельная таблица "для записей из которой будут браться ключи для parentID и childId" - в простой иерархической схеме структура выглядит как
id primary key (м.б. авто-генерируемым) parentId foreign key references table1 (ссылается на собственно эту же самую таблицу) прочие_поля Опять же RI обеспечивается автоматом - декларативным констрейном ссылочной целостности. Или нужно реализовать каскадное удаление узел и все его подузлы? Тыт я не в курсе- позволит или нет СУБД задать каскадную опцию для такого самоссылающегося констрейна. Но как по мне, так такая идея сама по себе "не очень". ------------------ WBR, Igor |
Re: Как элегантнее обеспечить ссылочную целостность (MS SQL) | |
---|---|
JS Автор Сообщений: 12264 Откуда: Эстония Дата регистрации: 04.09.2000 |
Спасибо за ответ, Игорь!
Начну с конца твоего ответа. Да, имелось ввиду именно каскадное удаление всех дочерних узлов при удалении корневого узла. Теперь по-поводу дополнительной таблицы к ссылочной таблицы. Просто опечатался - в отношении parentId - из дополнительной таблицы будут браться только сhildID, так как это не просто таблица, а словарь подуровней, которые могут подключаться к разным уровням вложения (например, проведение супервайзорского контроля может быть на двух трех ключевых по значению подуровнях, плюс еще несколько аналогичных вещей, которые могут быть также подкдючены к разным подуровням), плюс ко всему еще и локализация всех значений проектов, категорий и влоджений пока на четыре языка (прибалтийские и датский - контроллёры), и возможно добавятся еще два, что решается довольно просто с помощью таблицы языков и таблиц локализаций проекта, категорий и таблицы словаря подуровней. То есть при выборке данные будут браться из таблицы с локализованными данными. Кроме того, в этой же таблице можно ввести дополнительные поля по разграничению доступа к разным подуровням проекта - я так понял, что и это предполагается) . В общем стандартная процедура - "я не знаю что я хочу, но вы сделайте это прямо сейчас" Просто до момента написания топика еще не имел на руках всего проекта - только предложение по изменению структуры. Я бы все сделал изначально не так. Разработчик скис и не хочет продолжать развивать проект, а он вдруг понадобился. Все можно было с меньшими затратами сделать в Excel, но им хотелось иметь web интерефейс. ------------------ Knowledge is better than ignorance! Website: juri.foxhelp.eu |
© 2000-2024 Fox Club  |