|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
27.12.2006, 17:52
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
Добрый день или вечер (За окном темно). Помогите, пожалуйста. Есть три таблицы В каждой составной ключ. ПРичем атрибуты этого ключа сами по себе не уникальны(id, eff_start_date, eff_end_date), а уникален только сам составной ключ. Как сделать так чтобы при миграции в дочернюю таблицу мигрировал только id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.12.2006, 18:23
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
что ж в ней дочернего, если она не включает ключ родителя? Просто перетащите атрибут не создавая ER-связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.12.2006, 18:51
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
> В каждой составной ключ Меняйте дизайн. Это плохое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 10:14
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
guest_20040621> В каждой составной ключ Меняйте дизайн. Это плохое решение.А может и нормальное. Судя по названиям полей это что-то темпоральное / журнальное. Возможно, "дочерняя" таблица логически связана с данной условием на даты (например дата дочки должна попадать в диапазон дат родителя) и введение суррогата ничем не помогает - процедурный контроль диапазонов остается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 10:38
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
забыла для наглядности картинку приложить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 11:20
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
Поищите про темпоральные (исторические) базы данных. На поверхности: 1)Имена лучше давать в одном стиле - раз адрес и контакт, то человек а не люди. 2)Факт существования объекта и его история - разные сущности. Историю можно фиксировать как журнал событий, изменящих данные, или как статусы за период. People -> Pesron(неизменеямые со временем данные) + PersonStatus(изменяемые). 3)Для PersonStatus логично иметь в ключе дату начала, но не дату окончания периода, иначе сам ключ уже допускает два периода, начинающиеся с одной даты. Далее, связи между темпоральными сущностями могут быть постронеы по-разному: должна ли скажем история адреса быть синхронизирована с PersonStatus или она независима от него и родителем для нее является Person? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 12:13
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
ModelRПоищите про темпоральные (исторические) базы данных. На поверхности: 1)Имена лучше давать в одном стиле - раз адрес и контакт, то человек а не люди. 2)Факт существования объекта и его история - разные сущности. Историю можно фиксировать как журнал событий, изменящих данные, или как статусы за период. People -> Pesron(неизменеямые со временем данные) + PersonStatus(изменяемые). 3)Для PersonStatus логично иметь в ключе дату начала, но не дату окончания периода, иначе сам ключ уже допускает два периода, начинающиеся с одной даты. Далее, связи между темпоральными сущностями могут быть постронеы по-разному: должна ли скажем история адреса быть синхронизирована с PersonStatus или она независима от него и родителем для нее является Person? Замечания приняла. По поводу состава таблицы набазу новую запись " 123-Иванова Ирина Владимировна - 01.01.06 - (здесь пишится максимальаня дата)". Затем девушка выходит замуж и меняет фамилию ,и для того чтобы не заводить новый ID Делаем так "123 - Иванова Ирина Владимировна - 01.01.06 - 30.05.06" создается новая запись "123 - Петрова Ирина Владимировна - 30.05.06 - (и опять же макс. дата)" А в адресе и контакте нужен только ID для внешнего ключа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 13:38
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
> А может и нормальное. Очень сильно вряд ли. Я не могу придумать структуры, для которой составной ключ мог бы быть единственно правильным решением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 13:40
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
> По поводу состава таблицы Кривовато Вы задачу решили. Подумайте о декомпозиции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 15:41
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
guest_20040621> А может и нормальное. Очень сильно вряд ли. Я не могу придумать структуры, для которой составной ключ мог бы быть единственно правильным решением.А у меня вызывают подозрения структуры, где в каждой таблице единственное ограничение уникальности ID <тип> Pimary key. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 16:22
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
> А у меня вызывают подозрения структуры, где в каждой таблице единственное ограничение > уникальности ID <тип> Pimary key. Это стандартная, удобная, переносимая, однозначная идентификация. Должны быть очень веские причины, чтобы отказаться от такой схемы. Я таких причин не знаю; более того, их наличие склонен рассматривать как кривые руки архитектора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 16:55
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
2 guest_20040621 Вы обратили внимание на слово единственное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 17:16
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
ModelRА у меня вызывают подозрения структуры, где в каждой таблице единственное ограничение уникальности ID <тип> Pimary key. А что еще м.б. Pimary key ? ИНН, ФИО, паспорт, номер документа ? Все это не надежно, а потому неверно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 17:23
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
У меня единственный вопрос, есть ли такая функция которая отключает мигрирование всех атрибутов (мне нужно чтобы мигрировал только ID) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 17:41
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
> Вы обратили внимание на слово единственное? ;) Да. Фишка imho в том, что стандартный primary key - "архитектурная" гарантия уникальности, прочие ограничения уникальности - структурные, логические; т. е. я бы их не рассматривал на том же уровне, что и первичные ключи. Впрочем, это нюансы; формально возражений нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 18:49
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
schaumaУ меня единственный вопрос, есть ли такая функция которая отключает мигрирование всех атрибутов (мне нужно чтобы мигрировал только ID)Нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.12.2006, 18:54
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
модА что еще м.б. Pimary key ? ИНН, ФИО, паспорт, номер документа ? Все это не надежно, а потому неверно.Кто сказал Pimary ? уникальный. Для Person действительно ничего. А для PersonStatus пара (PersonId,StartDate) обязана быть уникальной. Вне завизимости, создан ли Primary PersonStatusId. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.12.2006, 01:57
|
|||
|---|---|---|---|
|
|||
Миграция ключей |
|||
|
#18+
schaumaДобрый день или вечер (За окном темно). Помогите, пожалуйста. Есть три таблицы В каждой составной ключ. ПРичем атрибуты этого ключа сами по себе не уникальны(id, eff_start_date, eff_end_date), а уникален только сам составной ключ. Как сделать так чтобы при миграции в дочернюю таблицу мигрировал только id Если есть уникальный id, зачем тогда в первичном ключе остальные атрибуты? Если id не уникален, тогда зачем он там? Если же id не уникален?!, тогда нельзя его использоват в качестве форин кея в другой таблице.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.12.2006, 10:09
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
ModelR А для PersonStatus пара (PersonId,StartDate) обязана быть уникальной. А вот это интересный вопрос. PersonStatus можно трактовать как факт изменения статуса, тогда этот факт должен иметь собственный ID, не зависящий от StartDate. А контроль уникальности (PersonId,StartDate) - это дополнительная фича - может быть, а может и не быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.12.2006, 10:44
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
мод ModelR А для PersonStatus пара (PersonId,StartDate) обязана быть уникальной. А вот это интересный вопрос. PersonStatus можно трактовать как факт изменения статуса, тогда этот факт должен иметь собственный ID, не зависящий от StartDate. Приведен был именно вариант статуса, не журнала событий (было бы PersonEvent): авторИсторию можно фиксировать как журнал событий, изменящих данные, или как статусы за период. People -> Pesron(неизменеямые со временем данные) + PersonStatus(изменяемые).А почему факт должен иметь собственный ID? Может, это 100% терминал и ссылок на него не бывает. модА контроль уникальности (PersonId,StartDate) - это дополнительная фича - может быть, а может и не быть.В контексте задачи ИМХО разные фамилии на одну дату - нонсенс. Хранение нонсенса как фича? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.12.2006, 10:55
|
|||
|---|---|---|---|
Миграция ключей |
|||
|
#18+
ModelRА почему факт должен иметь собственный ID? Может, это 100% терминал и ссылок на него не бывает. Собственно это и есть самое интересное. Я для себя взял за правило: всегда заводить ID в любой таблице. Как показала практика, ссылки рано или поздно, но появляются. Так зачем думать там где думать вредно - действуй по шаблону и все будет нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1544813]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 213ms |
| total: | 351ms |
| 0 / 0 |
