|
|
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
Создаю модель новой БД. Вкратце суть такая. Работники составляют акты. За составление актов им дают премию. Премия по акту делится в равных долях между составителями акта. Один акт могут составить несколько работников. Так как акт один, а составителей несколько, то создаём две таблицы: одна будет содержать данные акта, а вторая - работников по этому акту (один-к-одному-или-многим). Структура такая: Меня интересует связь между Act (данные по акту) и ActBonus (данные по премиям по каждому работнику в акте). Когда дошёл до создания таблицы ActBonus, то SQL Server заругался: " There are no primary or candidate keys in the referenced table 'dbo.Act' that match the referencing column list in the foreign key 'FK_Act_ActBonus_ActNumber' ": Код: sql 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. Здесь понятно - ошибка говорит о том, что поле Number не уникально. Чтобы решить данную проблему, я добавляю UNIQUE для Number в таблицу Act, и всё становится ОК: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Но ведь UNIQUE создаёт дополнительный некластерный индекс, а это дополнительный maintenance и overhead. Быть может, как-то можно сделать модель по-другому? Буду благодарен за предложения. :) Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 12:55 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
У Вас странный первичный ключ в Act - если поле Number уникально само по себе, какой смысл включать дополнительно в PK Period? Вам надо либо убрать Period из первичного ключа в Act, либо мигрировать его в ActBonus. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 13:53 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
Period - это отчётный месяц. Реально день составления акта может не совпадать с отчётным месяцем, поэтому использовать дату составления акта не представляется возможным. Соответственно, этот поле НЕ уникально. Number - это номер акта. Он уникален. Да, подходящий кандидат в primary key, но на деле он не нужен. Просто используется тот факт, что он уникален. Назначение базы таково, что она будет использоваться чисто для выгрузки отчётов, а поиска по номеру акта не будет производиться (ну если раз в год найти какой-нибудь акт :) ). Итак, на Period повесить кластерный индекс не получится, а на Period + Number можно. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2015, 14:29 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
MrVoid Меня интересует связь между Act (данные по акту) и ActBonus (данные по премиям по каждому работнику в акте). Когда дошёл до создания таблицы ActBonus, то SQL Server заругался: " There are no primary or candidate keys in the referenced table 'dbo.Act' that match the referencing column list in the foreign key 'FK_Act_ActBonus_ActNumber' ":. Вот у тебя какой первичный ключ в Act: constraint PK_Act primary key (Period, Number) Значит именно эти два поля должны входить и в ActBonus, в его первичный ключ. Не один ActNumber, а ДВА поля. Далее ты делаешь глупости -- уникальный ключ не может входит в состав другого ключа, это бессмысленно. Тебе надо для начала решить, какие поля будут первичнфм ключём в таблице Act , а затем перепроектировать из этих соображений таблицу ActBonus -- в её ПК должны входить все поля из ПК таблицы Act и все поля из таблицы Worker. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2015, 09:46 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
MrVoidPeriod - это отчётный месяц. Реально день составления акта может не совпадать с отчётным месяцем, поэтому использовать дату составления акта не представляется возможным. Соответственно, этот поле НЕ уникально. Number - это номер акта. Он уникален. Да, подходящий кандидат в primary key, но на деле он не нужен. Просто используется тот факт, что он уникален. Тут как бы ты должен решить, что использовать в качестве ПК, и всё. Мне кажется из твоих слов, что Period не должен быть в составе ПК, а должен быть просто атрибутом. Можно было бы сделать его UNIQUE, но для него неудачно выбран домен -- ты легко запихнёшь в таблицу данные с одинаковыми месяцами, но разными другими частями даты -- число месяца, час, мин. сек. -- так что нужны дополнительные ограничения на домен или поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2015, 09:50 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
@MasterZiv Различать Period по часу, минуте и секунде - это уж костыль какой-то. :) Хотя надо подумать. :) >>Далее ты делаешь глупости -- уникальный ключ не может входит в состав другого ключа, это бессмысленно. Identifying Relationship, не? Pro SQL Server 2008 Relational Database Design and Implementation Relationships come in several different flavors that indicate how the parent table is related to the child. We will look at examples of several different types of relationships in this section: • Identifying , where the primary key of one table is migrated to the primary key of another. The child will be a dependent entity. ... Не может или бессмысленно? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2015, 00:24 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
MrVoid>>Далее ты делаешь глупости -- уникальный ключ не может входит в состав другого ключа, это бессмысленно. Identifying Relationship, не? не. Ваще всё не о том. MrVoid Pro SQL Server 2008 Relational Database Design and Implementation Relationships come in several different flavors that indicate how the parent table is related to the child. We will look at examples of several different types of relationships in this section: • Identifying , where the primary key of one table is migrated to the primary key of another. The child will be a dependent entity. ... Не может или бессмысленно? :) Тут всё правильно написано, но ты неправильно понимаешь. migrated тут ключевое слово. Я же тебе говорю о другом совсем. Код: plaintext 1. -- вот это бессмыслица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2015, 22:26 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
@MasterZiv А как же тогда быть? По сути, уникальность номера акта мне совсем не нужна. Нужен только отчётный период. Быть может, к Period "прибавить" какой-нибудь искусственный ключ (Identity или Sequence)? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2015, 16:39 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
MrVoid, да именно так. Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK) Вам нужно сделать в Act одно поле первичного ключа (ID) и если нужно поставить ограничение уникальности на дополнительные поля Period и Number. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2015, 12:17 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
Malter Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK) Откуда взялось это "классическое правило"(tm)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 12:46 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMalter Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK) Откуда взялось это "классическое правило"(tm)? Холивар "естественные ключи vs суррогатные ключи"?! <:o) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 13:01 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
mad_nazgulКот Матроскинпропущено... Откуда взялось это "классическое правило"(tm)? Холивар "естественные ключи vs суррогатные ключи"?! <:o) Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 13:06 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинmad_nazgulпропущено... Холивар "естественные ключи vs суррогатные ключи"?! <:o) Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования" Согласен с вами. Классическим правилом проектирования можно считать как раз использование естественных ключей. Ну это если обратиться к классикам :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 13:39 |
|
||
|
Помогите с моделью БД
|
|||
|---|---|---|---|
|
#18+
mad_nazgulКот Матроскинпропущено... Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования" Согласен с вами. Классическим правилом проектирования можно считать как раз использование естественных ключей. Ну это если обратиться к классикам :-) Наверное я под КЛАССИЧЕСКИМ подразумевал лучшие практики - дальше можно спорить. Двойственность мира и возникающие в нем коллизии являются фундаментом для этой практики. Использование суррогатных ключей везде избавляет от множества проблем в реальных системах (не абстрактных или логических моделях). Я прекрасно понимаю о чем речь и ваше возмущение и не могу не согласиться с тем, что иногда не находится достаточного количества аргументов для того чтобы использовать суррогатный ключ в конкретной таблице. Но если эта реальная система взаимодействующая с другими системами, работающая и модифицирующаяся из года в год, то тем самым дополнительным аргументом станет ваш опыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2015, 14:42 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=22&tid=1540622]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
93ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 176ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...