|
|
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Добрый день. Нужен совет по схеме БД. Есть следующие таблицы: Цвета, Круги, Квадраты, НаборыФигур. Круги и квадраты могут быть любого цвета. Набор фигур состоит из одного круга и одного квадрата, одинакового цвета. Консистентность данных нужно обеспечивать декларативно. Нарисовал вот такую схемку: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Скрипт заполнения таблиц тестовыми данными: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Смущает только одно: введение [вроде бы] ненужных уникальных индексов в таблицах: unique (КодКруга, КодЦвета) и unique (КодТреугольника, КодЦвета). Ведь эти пары значений и так заведомо уникальны, поскольку в каждую пару входит первичный ключ. Вот это-то и не нравится: накладываем уникальность поверх уникальности. Хочется понять, так ли это необходимо в данном случае, или можно что-то поизящнее изобразить. Можно было бы, конечно, сделать первичные ключи в таблицах Круги и Треугольники составными (код фигуры + код цвета), тогда и FK по ним построится и без привлечения дополнительного unique constraint. Но хочется избежать составных ЕК, так как первичные ключи всех остальных таблиц базы - суррогатные и простые. Версия сервера 2005. Всем прочитавшим заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 10:56 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Упс, спутал квадраты с треугольниками :) Исправляюсь. Первый абзац следует читать так: Есть следующие таблицы: Цвета, Круги, Треугольники, НаборыФигур. Круги и треугольники могут быть любого цвета. Набор фигур состоит из одного круга и одного треугольника, одинакового цвета. Консистентность данных нужно обеспечивать декларативно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 10:59 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Перечитал сам себя и увидел, что структура приведенных таблиц и тестовые примеры данных противоречат мною же заявленному утверждению: "первичные ключи всех таблиц базы - суррогатные и простые". Поясню, пожалуй, чтобы не было путаницы. На самом деле, в примере приведены только прототипы реальных таблиц, поэтому для наглядности значения ключей сделаны "говорящими": 'К', 'С', 'З' и т.д., как бы на вид естественными, что ли. А в реальных таблицах там везде id int identity(1,1). Ну, не хотелось в примере загромождать все кучей цифр. Прошу прощения, если кого-то сбил с толку. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 11:11 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starter, Интересно, как будет выглядеть таблица [НаборыФигур], если к треугольникам и кругам прибавится еще с пяток типов фигур? Я, конечно, понимаю, что примитивов не так уж и много, но все ж таки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 16:14 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_L, понимаю вас. При увеличении количества типов фигур, наверно изящнее было бы проблему решить через промежуточную таблицу, так? Но набор всегда состоит только из двух фигур. Это, напоминаю, прототипы реальных таблиц, и у экземпляра сущности, названной здесь условно "Набор фигур", в действительности множество других атрибутов. Но эти два - неизменные (в том смысле, что всегда присутствуют, и всегда ровно два, и всегда должны быть одного "цвета"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 16:43 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Подискутирую-ка сам с собой :) Похоже, таблица НаборыФигур у меня не нормализована, поскольку там наблюдается некая зависимость неключевых атрибутов от другого неключевого же атрибута (цвет набора). Вопросы: 1. Действительно ли нарушена нормализация? 2. Что лучше делать? Оставить все как есть ("работает и ладно") или попытаться как-то оптимизировать? Например, вынести атрибуты, зависящие от цвета, в отдельную таблицу (правда, пока довольно смутно представляю, что мне это даст; нужно еще рисовать и смотреть...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:40 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starterСмущает только одно: введение [вроде бы] ненужных уникальных индексов в таблицах: unique (КодКруга, КодЦвета) и unique (КодТреугольника, КодЦвета). Ведь эти пары значений и так заведомо уникальны, поскольку в каждую пару входит первичный ключ. Вот это-то и не нравится: накладываем уникальность поверх уникальности. Хочется понять, так ли это необходимо в данном случае, или можно что-то поизящнее изобразить. Ограничения UNIQUE Вам ничего не дадут. ИМХО, у Вас направление связи неверное. То бишь это таблицы фигур должны ссылаться на [НаборыФигур]. Тогда можно будет декларативно ограничить и количество фигур в наборе и их цвет. Как и хотелось изначально. Да и поле [КодЦвета] можно перенести в [НаборыФигур]. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:44 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starterПодискутирую-ка сам с собой :)Ну что ж вы хотите? Жара, духота, все на водоемах или в теньке газеткой помахивают. А Вы хотите, чтобы сразу ответили... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:46 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Сформулируйте вопрос. Например 1 Таблицы Круги и квадраты очень большие с частой вставкой - поддержка дополнительных индексов накладна. Что делать? Ответ: забить на свое правило что первичный ключ не может составным. 2 Таблицы круги и квадраты статичные, наличие индекса напрягает только мое эстетическое чувство Ответ: я не вижу способа заставить SQLserver объявить ограничение внешнего ключа без использования ограничения уникальности, стало быть надо гасить свое эстетическое чувство. авторПри увеличении количества типов фигур, наверно изящнее было бы проблему решить через промежуточную таблицу, так?Не так. Вы как архитектор должны проработать вариант, а что если (по независящим от вас причинам) добавится еще одна фигура, что будет стоить переделать приложение. Если добавление дополнительной фигуры явление редкое (такое что под это дело будет патч на приложение и базу данных) тогда добавление дополнительного столбца (индексов, ограничений) тестирование наката патча и т.д. дело оправданное. Если же введение дополнительной фигуры - часть бизнеса, тогда лучше ввести дополнительную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:47 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_L, да, вы правы, ограничения UNIQUE позволили мне только лишь ограничения внешнего ключа создать (fk-констрэйнты). Другой вопрос, нужны ли они. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:47 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_Ltopic starterПодискутирую-ка сам с собой :)Ну что ж вы хотите? Жара, духота, все на водоемах или в теньке газеткой помахивают. А Вы хотите, чтобы сразу ответили...Сугубо уважаю право форумчан на субботний отдых в теньке у водоема! Фраза "подискутирую..." относилась исключительно к безудержному полету моей личной творческой фантазии :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 17:50 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
SERG1257, благодарю за развернутый ответ. Вот так и надо с нами, новичками - с пылесосом по мозгам пройтись. Из предложенных вами вариантов верен второй:SERG12572 Таблицы круги и квадраты статичные, наличие индекса напрягает только мое эстетическое чувствоДа, эти таблицы представляют собой род справочников, одна из них заполняется первый раз при старте системы и практически не меняется потом (редко, раз в год-два). Другая обнуляется и заполняется ежегодно. SERG1257Вы как архитектор должны проработать вариант, а что если (по независящим от вас причинам) добавится еще одна фигура, что будет стоить переделать приложение. Если добавление дополнительной фигуры явление редкое (такое что под это дело будет патч на приложение и базу данных) тогда добавление дополнительного столбца (индексов, ограничений) тестирование наката патча и т.д. дело оправданное. Если же введение дополнительной фигуры - часть бизнеса, тогда лучше ввести дополнительную таблицу.Окей. Добавление фигуры - не часть бизнеса. Это явление (по уверениям составителей ТЗ) чрезвычайно маловероятное. Ну, как атрибут банковского документа, что ли. Таких атрибутов ведь известное количество: расчетный счет, БИК, ИНН, бла-бла-бла, и новый атрибут вот так вот из воздуха появиться не может Получается, что представленная схема выглядит оптимальной? И, поскольку "способа заставить SQLserver объявить ограничение внешнего ключа без использования ограничения уникальности нет", то на эстетическое чувство придется наступить грязным ботинком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:03 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starterSenya_L, да, вы правы, ограничения UNIQUE позволили мне только лишь ограничения внешнего ключа создать (fk-констрэйнты). Другой вопрос, нужны ли они.Та не нужны они. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:05 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_LЗаметьте, просто удалил две строчки исходного скрипта :) Сейчас-сейчас [потирает руки], испробую ваш вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:08 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starterSenya_LЗаметьте, просто удалил две строчки исходного скрипта :) Сейчас-сейчас [потирает руки], испробую ваш вариант.Ну тады попробуйте и еще такой рабоче-крестьянский вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:13 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_L, посмотрел внимательней. Вы зачем атрибут "Цвет" из таблиц "Круги" и "Квадраты" исключили? Они у меня все раскрашенные, не могут они прозрачными быть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:14 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
topic starterSenya_L, посмотрел внимательней. Вы зачем атрибут "Цвет" из таблиц "Круги" и "Квадраты" исключили? Они у меня все раскрашенные, не могут они прозрачными быть :)авторНабор фигур состоит из одного круга и одного квадрата, одинакового цвета.Зачем поле цвет в таблицах фигур, если он уже определен в таблице НаборыФигур? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:15 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_LНу тады попробуйте и еще такой рабоче-крестьянский вариант Да, вариант и правда какой-то... серпасто-молоткастый. Вынесение атрибутов в отдельную таблицу атрибутов имело бы смысл, если бы ожидалось регулярное изменение как числа самих атрибутов, так и их количества в наборе. А у меня по ТЗ - атрибутов, зависящих от цвета, вообще всегда только два. И добавляться они не будут. И в наборе и два и ровно два всегда. Смысл иметь отдельную таблу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:18 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_LЗачем поле цвет в таблицах фигур, если он уже определен в таблице НаборыФигур? Затем, что таблицей НаборыФигур эта БД не ограничивается. Красные круги и синие треугольники - экземпляры справочников. Они существуют (как явления) и сами по себе, без наборов. В наборы они только входят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:20 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
авторДа, вариант и правда какой-то... серпасто-молоткастый.Это одобрение или порицание? :) topic starterSenya_LЗачем поле цвет в таблицах фигур, если он уже определен в таблице НаборыФигур? Затем, что таблицей НаборыФигур эта БД не ограничивается. Красные круги и синие треугольники - экземпляры справочников. Они существуют (как явления) и сами по себе, без наборов. В наборы они только входят.Тогда не понимаю. Вы сформулировали свою задачу абстрактно на примере фигур. Так вот судя по Вашему примеру поле КодЦвета в таблицах фигур не нужно. Что Вы видите исходя по реальной постановке - простите, отсюда не видно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:26 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Senya_LЭто одобрение или порицание? :)Изумление :) topic starterВы сформулировали свою задачу абстрактно на примере фигур. Так вот судя по Вашему примеру поле КодЦвета в таблицах фигур не нужно. Что Вы видите исходя по реальной постановке - простите, отсюда не видно.Да, признаю, дал маху, перестарался с абстракцией. Хотел, чтобы было наглядно и понятно, чтобы не тащить сюда нашу производственную БД и утомлять описаниями, что от чего там должно зависеть. Приношу извинения. Описывая часть БД схематично, я предполагал, что сущности Цвета, Круги, Треугольники а) уже существуют и б) связаны между собой именно таким образом, как описано в примере (то есть изменению эта часть схемы не подлежит). Интересовала только таблица НаборыФигур, а точнее - реализация декларативного ограничения ее целостности наиболее элегантным способом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 18:31 |
|
||
|
Внешний ключ: обойтись без дополнительного уникального индекса?
|
|||
|---|---|---|---|
|
#18+
Вопрос решен. Оставляю структуру таблиц как есть. Благодарю Senya_L за отзывчивость и терпение, а SERG1257 - за промывку мозгов и напоминание о том, что правильно поставленный вопрос содержит в себе половину ответа :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2010, 19:10 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36709435&tid=1542644]: |
0ms |
get settings: |
6ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
155ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 420ms |

| 0 / 0 |
