ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор PK
25 сообщений из 46, страница 1 из 2
  1  все
Выбор PK
    #33216966
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
С поиском на скуле снова туговато, поэтому не бейте, если вопрос уже задавали.
Мимоходом слышал, о том что выбор identity field в качестве PK - кривое решение. Хочется узнать почему?
К примеру у нас имеется несколько областных серверов и один центральный. У каждого из серверов PK - это identity с определенной областью значений, которая не перекрывается PK других серверов. Кроме PK конечно же есть ещё и unique key. Все областные сервера реплицируются на центральный сервер. Манипулировать, настраивать репликацию и пр. пр., по-моему легче с PK из одного поля, чем составным. В чем же тогда цимус?
...
Рейтинг: 0 / 0
16.08.2005, 10:15
| Ответить | Цитировать | Написать  
Выбор PK
    #33217129
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>> Манипулировать, настраивать репликацию и пр. пр., по-моему легче с PK из одного поля, чем составным.
Это почему?
...
Рейтинг: 0 / 0
16.08.2005, 10:51
| Ответить | Цитировать | Написать  
Выбор PK
    #33217175
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
gardenmanЭто почему?
:) Берём просто манипуляцию (при репликации я получаю горизонтальные и вертикальные сабсеты, поэтому репликацию сюда сунул).
ведь куда проще написать:
Код: plaintext
1.
2.
3.
select *
from table1 t1
where t1.id not in (select t2.id from table2 t2)
чем
Код: plaintext
1.
2.
3.
select *
from table1 t1
where (t1.id1, t1.id2, t1.id3....) <> (select....

Не могу найти, кто говорил про минусы identity as PK пока поиск не работает. Просто сейчас стало интересно - почему?
...
Рейтинг: 0 / 0
16.08.2005, 10:58
| Ответить | Цитировать | Написать  
Выбор PK
    #33217274
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ГостиМимоходом слышал, о том что выбор identity field в качестве PK - кривое решение. Хочется узнать почему?
Возможно я не понимаю, что такое identity field, но если не ошибаюсь, его для этого и придумывали. Соответственно, такое утверждение эквивалентно утверждению "identity не должны использоваться".

На аргументацию этого утверждения и мне хотелось бы полюбоваться. Единственный вариант, который я вижу - недобитый фанатик естественных ключей.
...
Рейтинг: 0 / 0
16.08.2005, 11:17
| Ответить | Цитировать | Написать  
Выбор PK
    #33217298
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
identity - автоинкрементное поле.
...
Рейтинг: 0 / 0
16.08.2005, 11:24
| Ответить | Цитировать | Написать  
Выбор PK
    #33217323
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Ну хорошо, положим что у вас единственное поле в ПК, причем разбито по диапозонам для филиалов. И пусть все ложится в консолидированную базу.
И, пожалуйста нарисуйте мне запрос сгруппируйте все по филиалам. Или положим в каком-то филиале грохнулась база. Сделайте экстракт данных для этого филиала из консолидированной. И, путь допустим диапазон по какой-либо причине перекрылся (мало ли какая ошибка) что делать в этом случае? Я не говорю что все это сделать невозможно. Пусть каждый живет с тем геморроем который ему нравится. Удачи.
...
Рейтинг: 0 / 0
16.08.2005, 11:30
| Ответить | Цитировать | Написать  
Выбор PK
    #33217336
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Гости gardenmanЭто почему?
:) Берём просто манипуляцию (при репликации я получаю горизонтальные и вертикальные сабсеты, поэтому репликацию сюда сунул).
ведь куда проще написать:
Код: plaintext
1.
2.
3.
select *
from table1 t1
where t1.id not in (select t2.id from table2 t2)
чем
Код: plaintext
1.
2.
3.
select *
from table1 t1
where (t1.id1, t1.id2, t1.id3....) <> (select....
it depends
в постгресе работает конструкция
where [NOT] (t1.id1, t1.id2, t1.id3....) in (select id1,id2,id3 FROM ....)
при этом ничто не мешает писать и так:
where NOT EXISTS (select ... WHERE t2.id1=t1.id1 AND t2.id2=t1.id2 AND t2.id3=t1.id3)
...
Рейтинг: 0 / 0
16.08.2005, 11:32
| Ответить | Цитировать | Написать  
Выбор PK
    #33217350
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
авторНу хорошо, положим что у вас единственное поле в ПК, причем разбито по диапозонам для филиалов. И пусть все ложится в консолидированную базу.
И, пожалуйста нарисуйте мне запрос сгруппируйте все по филиалам. Или положим в каком-то филиале грохнулась база. Сделайте экстракт данных для этого филиала из консолидированной. И, путь допустим диапазон по какой-либо причине перекрылся (мало ли какая ошибка) что делать в этом случае? Я не говорю что все это сделать невозможно. Пусть каждый живет с тем геморроем который ему нравится. Удачи.
что за? объясните по порядку, чем здесь составной ключ будет лучше не составного и с чего такой тон?
...
Рейтинг: 0 / 0
16.08.2005, 11:35
| Ответить | Цитировать | Написать  
Выбор PK
    #33217367
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Гости чем здесь составной ключ будет лучше не составного и с чего такой тон?
ключ(ид_филиала, ид_чегохошь) свободен от необходимости расщеплять поле, и от возможности наложения интервалов ("паашибке"). А т.к. это оказалось непонятным - то видимо и тон.
...
Рейтинг: 0 / 0
16.08.2005, 11:38
| Ответить | Цитировать | Написать  
Выбор PK
    #33217373
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Ага, а теперь сравним эти запросы по производительности с простым
select * from table where filial=..., причем поле filial первое поле первичного ключа.))) Я соглашусь, что можно такую фигню использовать если в табличке несколько тысяч записей. А если несколько миллионов? Интересно на какую производительность вы расчитываете?
...
Рейтинг: 0 / 0
16.08.2005, 11:38
| Ответить | Цитировать | Написать  
Выбор PK
    #33217394
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
4321it depends
в постгресе работает конструкция
where [NOT] (t1.id1, t1.id2, t1.id3....) in (select id1,id2,id3 FROM ....)
при этом ничто не мешает писать и так:
where NOT EXISTS (select ... WHERE t2.id1=t1.id1 AND t2.id2=t1.id2 AND t2.id3=t1.id3)
конструкции не важны в принципе. Вопрос о выборе PK: составной or identity.

Берем другой пример: внешние ключи в БД.
При составном ключе, внешний ключ тоже будет составным.

зы. я не являюсь ярым сторонником того или другого метода. Мне интересно почему кое-кто считает identity злом?
...
Рейтинг: 0 / 0
16.08.2005, 11:42
| Ответить | Цитировать | Написать  
Выбор PK
    #33217414
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
зы. я не являюсь ярым сторонником того или другого метода. Мне интересно почему кое-кто считает identity злом?
Зло не identity, а неразумное его его использование повсюду.
...
Рейтинг: 0 / 0
16.08.2005, 11:46
| Ответить | Цитировать | Написать  
Выбор PK
    #33217436
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
gardenmanАга, а теперь сравним эти запросы по производительности с простым
select * from table where filial=..., причем поле filial первое поле первичного ключа.))) Я соглашусь, что можно такую фигню использовать если в табличке несколько тысяч записей. А если несколько миллионов? Интересно на какую производительность вы расчитываете?

и что? кроме первичного ключа в виде identity - обязательно есть альтернативный ключ. пусть filial будет "первым полем альтернативного ключа" - что изменится в производительности?
...
Рейтинг: 0 / 0
16.08.2005, 11:49
| Ответить | Цитировать | Написать  
Выбор PK
    #33217477
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
А зачем нужно два индекса, если можно обойтись одним?
...
Рейтинг: 0 / 0
16.08.2005, 11:57
| Ответить | Цитировать | Написать  
Выбор PK
    #33217524
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
авторА зачем нужно два индекса, если можно обойтись одним?

для вот этого к примеру:

Код: plaintext
1.
2.
delete from table1 t1
where t1.id in (select t2.id from table2 t2 where t2.altkey1="sdf" and t2.altkey2="23" ....)
куда более понятней, чем
Код: plaintext
1.
2.
delete from table1 t1
where (t1.pk1, t1.pk2, ....) in (select t2.fk1, t2.fk2, .... from table2 t2 where ....
id-identity as PK
altkey - alternative key
pk - primary key
fk - foreign key

надо будет кстати протестировать подобное, что быстрее:
поиск по индексу составного альтернативного ключа + поиск по уникальному не составному индексу или
поиск по индексу составного внешнего ключа + поиск по составному уникальному индексу?
...
Рейтинг: 0 / 0
16.08.2005, 12:07
| Ответить | Цитировать | Написать  
Выбор PK
    #33217556
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
А почему это вы решили что у вас в системе будет только поиск по индексу ? Намекаете на INDEX ORING/ANDING? Думаете это простые операции? А insert, update, delete? Вы попробуйте куда будут вставляться быстрее записи -
в табличку где один индекс или два?
Если табличка у вас - просто справочник который обновляется пару раз в день, то конечно можно нарисовать пару десятков индексов. А если это не так?
...
Рейтинг: 0 / 0
16.08.2005, 12:13
| Ответить | Цитировать | Написать  
Выбор PK
    #33217591
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
авторА почему это вы решили что у вас в системе будет только поиск по индексу? Намекаете на INDEX ORING/ANDING? Думаете это простые операции? А insert, update, delete? Вы попробуйте куда будут вставляться быстрее записи -
в табличку где один индекс или два?
Если табличка у вас - просто справочник который обновляется пару раз в день, то конечно можно нарисовать пару десятков индексов. А если это не так?

ок. Для OLTP - схема действительно не самая подходящая. Ура, наконец то что то есть.
А вот по поводу поиска только/не только по индексу:
причем здесь это? при table scan и пр. неиндексиронном поиске как будет влиять структура ключа?
...
Рейтинг: 0 / 0
16.08.2005, 12:21
| Ответить | Цитировать | Написать  
Выбор PK
    #33217612
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
gardenmanИ, пожалуйста нарисуйте мне запрос сгруппируйте все по филиалам.
Код: plaintext
select ... group by division_id

gardenmanИли положим в каком-то филиале грохнулась база. Сделайте экстракт данных для этого филиала из консолидированной.
Ээ.. надо писать?

Хотя в первую очередь надо не экстракт делать, а админа увольнять, у которого в мирное время невосстановимо грохается база.

gardenmanИ, путь допустим диапазон по какой-либо причине перекрылся (мало ли какая ошибка) что делать в этом случае?
Писать прокламацию производителю СУБД. Примерно так - я, мол, делаю

Код: plaintext
create sequence S minvalue  1000  maxvalue  2000

а он, сволочь, полез в чужой диапазон.

gardenmanЯ не говорю что все это сделать невозможно. Пусть каждый живет с тем геморроем который ему нравится.
Вот уж точно. Я правильно понимаю, что для Вас group by division_id - аргумент за составной ключ?
...
Рейтинг: 0 / 0
16.08.2005, 12:24
| Ответить | Цитировать | Написать  
Выбор PK
    #33217653
Гости
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гости
Участник
авторНамекаете на INDEX ORING/ANDING? Думаете это простые операции?
INDEX ORING/ANDING в вышеприведенном примере с запросами как то имеет значение? Запросы со стороны кол-ва индексов и ORING/ANDING равноправны имхо. черт с ними это частный случай. Сейчас подумаю, где ORING/ANDING для identity и составного будут в пользу того или другого...
...
Рейтинг: 0 / 0
16.08.2005, 12:30
| Ответить | Цитировать | Написать  
Выбор PK
    #33217655
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
gardenmanА зачем нужно два индекса, если можно обойтись одним?
Можно обойтись и вообще без индексов. Вопрос в том, нужно ли.

Вопрос "что есть оптимально", как мы все догадываемся, вряд ли имеет конкретный и одновременно универсальный ответ. Например, пара индексов PK:(id_field), INDEX:(division, field_a, field_b, field_c) запросто может оказаться предпочтительнее, нежели пара индексов PK:(division, field_a), INDEX:(division, ....)
...
Рейтинг: 0 / 0
16.08.2005, 12:31
| Ответить | Цитировать | Написать  
Выбор PK
    #33217823
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
softwarer Я правильно понимаю, что для Вас group by division_id - аргумент за составной ключ?
нет, аргумент тут скорее редкая, но таки возможная ситуация, когда базы ставились как заведомо независимые (т.е. никто не написал заранее разных минимумов и максимумов на диапазоны), а потом таки оказалось, что данные надо слить. Кажется таки отапдейтить ид_дивижна проще, чем сдвинуть счетчик (некоторые субд к тому же проверяют уникью на каждую запись, а не на стейтмент - придеца делать апдейт на ОрдернутуюБайДеск таблицу - лишние слова в пестне, однако).
...
Рейтинг: 0 / 0
16.08.2005, 13:10
| Ответить | Цитировать | Написать  
Выбор PK
    #33217838
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
ЗЫ. кстати мой вариант ключа такой:
(ид_филиал, счетчик),
а не десять полей.

Но это скорее от привычки иметь дело с базами (в филиалах), где изначально нет ни ай-ди_филиал, ни выделенных диапазонов.
...
Рейтинг: 0 / 0
16.08.2005, 13:14
| Ответить | Цитировать | Написать  
Выбор PK
    #33217876
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Можно обойтись и вообще без индексов. Вопрос в том, нужно ли.
Ну если проектировать базу так как вы советуете, то в конце концов как раз так и получится, что система не будет использовать индексы несмотря на то, что они есть.

Я правильно понимаю, что для Вас group by division_id - аргумент за составной ключ?
А вам этого аргумента значит не хватает?

пара индексов PK:(division, field_a), INDEX:(division, ....)
А с чего это вы решили, что второй индекс я обязательно начну с division?
А вдруг у меня имеются поля с большей селективностью?
И вообще, я говорил о том, что этот ваш второй индекс мне может вообще не понадобится.

И вообще сыр-бор как я понимаю только из-за того, что кто-то очень хочет писать
update/delete... where id=:id
вместо
update/delete .... where (division_id,id)=(:division_id,:id)

потому, что в первом варианте короче?

Сдается мне что причина вообще несколько в другом. У MSSQL имеется только IDENTITY поле, которое обязательно подразумемает индекс. У того же Оракла и ДБ2 есть SEQUENCE. (У ДБ2 есть и IDENTITY тоже в дополнение к SEQUENCE).
Соответственно и подходы диктуются используемым сервером БД.
...
Рейтинг: 0 / 0
16.08.2005, 13:26
| Ответить | Цитировать | Написать  
Выбор PK
    #33217895
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
4321нет, аргумент тут скорее редкая, но таки возможная ситуация, когда базы ставились как заведомо независимые (т.е. никто не написал заранее разных минимумов и максимумов на диапазоны), а потом таки оказалось, что данные надо слить. Кажется таки отапдейтить ид_дивижна проще, чем сдвинуть счетчик
Первое, что в этом случае придется делать - ВВОДИТЬ ид_дивижна, поскольку в "заведомо независимых" базах его не будет. Второе - переписывать все селекты, которые про ид_дивижна знать ничего не знают (в данном случае я предполагаю, что авторы СУБД не настолько законченные идиоты, чтобы пользоваться NATURAL JOIN или аналогичными неявными конструкциями). Ну и само собой, потребуется решить еще кучу неприятных вопросов - согласование справочников, сведение данных, изменения задним числом...

В общем, я бы сказал, это практически в любом случае настолько неприятная процедура, что лучше не давать ей шанса на жизнь. Наверное, можно найти случаи, когда вместо ид_дивижна можно заюзать какой-то подходящий справочник и решить задачу дешево, типа "был справочник с записями ОТДЕЛ1, ОТДЕЛ2, стал справочник с записями ФИЛИАЛ1_ОТДЕЛ1, ФИЛИАЛ1_ОТДЕЛ2", но это вряд ли часто возможно и это совершенно точно не очень-то хорошо.
...
Рейтинг: 0 / 0
16.08.2005, 13:32
| Ответить | Цитировать | Написать  
Выбор PK
    #33217913
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Преписывать селекты?... хм.. что-то я сомневаюсь что это нужно будет делать.
ALTER TABLE - может и придется сделать а вот переписывать селекты - зачем?

А если у филиалов вдруг пересекаются диапазоны - вот тогда это действительно круто...
...
Рейтинг: 0 / 0
16.08.2005, 13:36
| Ответить | Цитировать | Написать  
25 сообщений из 46, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Выбор PK
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]