![]() |
|
Модераторы: LSD |
![]()
|
|
| oson |
|
|||
![]() Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 289 Регистрация: 3.3.2004 Где: Севастополь Репутация: нет Всего: 1 |
Господа!
Помогите решить спор. Мой PM сам создал базу. При этом там имеется две таблицы - ADDRESSES и COMPANY_ADDRESSES. Он хочет, чтоб в таблице ADDRESSES поля COUNTRY,STREET, HOUSENUMBER составляли Primary Key. При этом в таблице COMPANY_ADDRESSES есть 3 таких же поля, которые являются FK на таблицу ADDRESSES. Я предложил сделать ID суррогатным и эти три поля уникальными. Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate. Тогда он согласился так сделать (с ID и тремя уникальными полями), но при этом оставил такие же 3 поля (COUNTRY,STREET, HOUSENUMBER) и в таблице COMPANY_ADDRESSES. И агументировал тем, что если понадобиться прочитать эти поля для COMPANY_ADDRESSES, то Oracle не будет обьединять эти 2 таблицы по ADDRESSES.ID, а просто прочитает их из COMPANY_ADDRESSES. Честно говоря, я не видел раньше такого и кажется дублировать поля в 2 таблицах неразумно. Решил посоветоваться - может я неправ. И вот вопросы 1) В чем преимущества суррогатного ключа? 2) Ускоряет ли дублирование полей в нескольких таблицах быстродействие базы? |
|||
|
||||
| 3x3 |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 261 Регистрация: 17.9.2006 Репутация: 2 Всего: 8 |
У вас ADDRESSES - это база домов что-ли? Так и назвали бы HOUSES. А COMPANY_ADDRESS логично бы ссылался на конкретный дом по суррогатному ключу плюс содержал бы ещё идентификатор конкретного офиса в доме и т.п. Если же база домов не требуется, то и сущность можно не создавать имхо.
Это сообщение отредактировал(а) 3x3 - 8.1.2007, 15:50 -------------------- Зачем платить больше, когда можно заплатить дважды? |
|||
|
||||
| LSD |
|
|||
![]() Leprechaun Software Developer ![]() ![]() ![]() ![]() Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 18 Всего: 538 |
Не привязан к данным, и как следствие при любых изменениях данных, не требует перестройки индексов, внешних ключей и т.п. Может быть уникальным, в пределах группы таблиц, или группы БД. Вот статейка на данную тему: Естественные ключи против искусственных ключей
Если таблицы будут в индексном кластере, и большая часть запросов будет делать JOIN по индексным полям. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
![]()
|
| Правила форума "Oracle" | |
|
|
Данный раздел предназначен для обсуждения проблем с Oracle Database, другие продукты Oracle здесь не обсуждаются. Просьба при создании темы, придерживаться следующих правил:
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Zloxa, LSD. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Oracle | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |