Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Безумно большой первичный ключ / 20 сообщений из 20, страница 1 из 1
23.11.2009, 16:03
    #36326250
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Собственно вопрос: какого размера ключ - "слишком большой"? Имеется в виду в основном суммарный размер составного ПК.

Хочу знать на какой размер можно рассчитывать для баз, спроектированных вменяемыми людьми.
...
Рейтинг: 0 / 0
23.11.2009, 16:10
    #36326287
Сергей Васкецов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry Sibiryakovсоставного ПК
О какой вменяемости в общем случае может идти речь?
...
Рейтинг: 0 / 0
23.11.2009, 16:44
    #36326428
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry Sibiryakov wrote:

> Собственно вопрос: какого размера ключ - "слишком большой"? Имеется в
> виду в основном суммарный размер составного ПК.

В общем случае, наверное, более 5 полей или более 512 байт по
своей суммарной длине. В частных случаях могут быть отклонения
как в ту, так и в другую сторону.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
23.11.2009, 17:48
    #36326620
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Я бы сказал что ДВА (второе поле для распределенной системы) поля - максимум для первичного ключа (большее количество необходимо обосновывать). Остальное лучше обозвать альтернативным ключом и для ссылочной целостности не использовать.
...
Рейтинг: 0 / 0
23.11.2009, 17:57
    #36326653
ChA
ChA
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry SibiryakovСобственно вопрос: какого размера ключ - "слишком большой"? Имеется в виду в основном суммарный размер составного ПК.Чем меньше, тем лучше, особенно, если он может мигрировать далее. Желательно фиксированного типа, еще лучше - целочисленного.

P.S. Как-то видел очень печальные последствия применения для master-таблицы в качестве PK varchar-строки размером 40-50 байт на Informix.
...
Рейтинг: 0 / 0
23.11.2009, 22:40
    #36327105
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry SibiryakovХочу знать на какой размер можно рассчитывать для баз, спроектированных вменяемыми людьми.
Я работал с базой, где первичный ключ некоторых таблиц насчитывал двенадцать полей, в среднем было пять-шесть. "Спроектированных вменяемыми людьми" я совершенно не почувствовал.
...
Рейтинг: 0 / 0
23.11.2009, 23:51
    #36327187
iscrafm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
больше одного уже тяжело, человек явно не может определиться с сущностями. 12... хм..
...
Рейтинг: 0 / 0
24.11.2009, 09:32
    #36327478
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Разовьем тему. Интересуют распределенные базы. Видится три варианта реализации первичного ключа в этом случае:
1. UUID. Плюс: поле атомарно и как утверждается риск неуникальности ничтожен. Минус - поле большое, не все СУБД его поддерживают. Сам ключ не говорит о месте (базе) создания данных.
2. Держать пару полей (код базы создания объекта, уникальный код в этой базе), во внешних ключах также пара данных. Плюс - можно однозначно идентифицировать какая база породила эту запись. Минус - внешние ключи достаточно большие. Работа с неатомарными значениями.
3. Первичный ключ - одно поле уникальное в базе. Кроме того существует еще уникальная пара полей (как в варианте 2), не входящих в базу, но являющихся синхронизаторами между базами. Первичный ключ не мигрирует между базами. Плюс - первичный и внешние ключи атомарны. Минус - дополнительные 2 поля (уникальный индекс), единственная нагрузка которых обеспечить синхронизацию данных.
Прошу обсудить каждый из подходов, возможно, у вас есть решение и получше.

С уважением, Naf
...
Рейтинг: 0 / 0
24.11.2009, 10:27
    #36327613
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Не думаю, что Дмитрий имел в виду именно эту тему, и не понимаю, зачем городить сложности, когда существует общеупотребимое, простое и правильное решение:

Код: plaintext
create sequence SOME_ID start with <номер сервера> increment by  1000 ;
...
Рейтинг: 0 / 0
24.11.2009, 10:45
    #36327674
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
softwarerНе думаю, что Дмитрий имел в виду именно эту тему, и не понимаю, зачем городить сложности, когда существует общеупотребимое, простое и правильное решение:

Код: plaintext
create sequence SOME_ID start with <номер сервера> increment by  1000 ;
где оно существует? и как эти средством пользоваться?
...
Рейтинг: 0 / 0
24.11.2009, 11:20
    #36327804
sn1251
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Nafгде оно существует? и как эти средством пользоваться?
Oracle, PostgreSQL, Sybase ASA
...
Рейтинг: 0 / 0
24.11.2009, 11:36
    #36327877
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
sn1251,

в целом понятно, ну а если баз стало больше 1000? в действующем проекте
...
Рейтинг: 0 / 0
24.11.2009, 12:10
    #36328010
ОКТОГЕН
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Naf, UUID и UUID-OSSP ваше всё.
Что-то подобное есть в любой СУБД.
...
Рейтинг: 0 / 0
24.11.2009, 12:12
    #36328016
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
ОКТОГЕНNaf, UUID и UUID-OSSP ваше всё.
Что-то подобное есть в любой СУБД.неплохой вариант, но нет информации о базе-создателе, придется еще одно поле вносить
...
Рейтинг: 0 / 0
24.11.2009, 12:17
    #36328030
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Nafв целом понятно, ну а если баз стало больше 1000?
(пожимая плечами) Никто не мешает increment by 1000000. Я не встречал проекта, где нельзя было бы сразу оценить "заведомо недостижимую" цифру количества.
...
Рейтинг: 0 / 0
24.11.2009, 12:26
    #36328061
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
softwarerNafв целом понятно, ну а если баз стало больше 1000?
(пожимая плечами) Никто не мешает increment by 1000000. Я не встречал проекта, где нельзя было бы сразу оценить "заведомо недостижимую" цифру количества.в общем тоже неплохая идея, как и все со своими плюс/минусами разумеется
...
Рейтинг: 0 / 0
24.11.2009, 14:02
    #36328385
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
softwarerНе думаю, что Дмитрий имел в виду именно эту тему
Ну, вообще-то примерно эту тему я и имел ввиду, поскольку распределённые БД - моя работа. Но перечисленные варианты слишком простые. GUID это всего лишь 16 байт в двоичном представлении и 32 в текстовом. Два нумерика - ещё проще. Про распределение по диапазонам я вообще молчу.

Максимум, что я видел в клиентских базах это 3-4 поля суммарной длиной 40-50 в символьном представлении. Но теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Жар-птичка - до 4096.
...
Рейтинг: 0 / 0
24.11.2009, 14:09
    #36328405
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry SibiryakovsoftwarerНе думаю, что Дмитрий имел в виду именно эту тему
Ну, вообще-то примерно эту тему я и имел ввиду, поскольку распределённые БД - моя работа. Но перечисленные варианты слишком простые. GUID это всего лишь 16 байт в двоичном представлении и 32 в текстовом. Два нумерика - ещё проще. Про распределение по диапазонам я вообще молчу.

Максимум, что я видел в клиентских базах это 3-4 поля суммарной длиной 40-50 в символьном представлении. Но теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Жар-птичка - до 4096.а что не так с размером? не хватает? 0_о
а с распределением? а вам не все равно? это же суррогат
...
Рейтинг: 0 / 0
24.11.2009, 14:35
    #36328507
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Nafа что не так с размером? не хватает? 0_о
Наоборот - лишко. У меня в таблице протокола есть поле (даже два), в которые записываются значения ключей. Если эти поля слишком большие - падает производительность. Слишком маленькие - ...., ну, всем ясно. Вот, ищу баланс с помощью народного мнения.
Настройку в руки пользователя я, конечно, дам, но нужно осмысленное значение по умолчанию для тех, кто не заморачивается чтением документации и ковырянием настроек.
...
Рейтинг: 0 / 0
24.11.2009, 21:59
    #36329539
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Безумно большой первичный ключ
Dimitry SibiryakovНу, вообще-то примерно эту тему я и имел ввиду,
Вы говорите про размер. А Naf - про архитектурные вариации, которые, исключая UUID, с размером связаны крайне мало.

Dimitry SibiryakovНо теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт.
Cомнительная цифра.

Код: 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.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
Connected to Oracle Database 10g Express Edition Release  10 . 2 . 0 . 1 . 0  
Connected as test

SQL> set serveroutput on;
SQL> declare
   2     fsize varchar( 15 ) := '(2000 byte)';
   3     pk varchar2( 32000 ) := 'i1';
   4   
   5     procedure exec (stmt varchar2) is
   6     begin
   7       dbms_output.put_line (stmt);
   8       execute immediate stmt;
   9     exception
  10       when others then dbms_output.put_line (sqlerrm);
  11       raise;
  12     end;
  13   
  14   begin
  15     exec ('create table pkmax (i1 char' || fsize || ')');
  16     for i in  2 .. 1000  loop
  17       if i >  2  then exec ('alter table pkmax drop primary key'); end if;
  18       exec ('alter table pkmax add i' || i || ' char' || fsize);
  19       pk := pk || ', i' || i;
  20       begin
  21         exec ('alter table pkmax add primary key (' || pk || ')');
  22       exception
  23         when others then
  24           dbms_output.put_line ('Навернулось на ключе из ' || i || ' полей');
  25           exit;
  26       end;
  27     end loop;
  28     exec ('drop table pkmax');
  29   exception
  30     when others then
  31       exec ('drop table pkmax');
  32       raise;
  33   end;
  34   /
create table pkmax (i1 char( 2000  byte))
alter table pkmax add i2 char( 2000  byte)
alter table pkmax add primary key (i1, i2)
alter table pkmax drop primary key
alter table pkmax add i3 char( 2000  byte)
alter table pkmax add primary key (i1, i2, i3)
alter table pkmax drop primary key
alter table pkmax add i4 char( 2000  byte)
alter table pkmax add primary key (i1, i2, i3, i4)
ORA- 01450 : maximum key length ( 6398 ) exceeded
Навернулось на ключе из  4  полей
drop table pkmax

PL/SQL procedure successfully completed

Я так полагаю, максимальный размер ключа в Oracle определяется размером блока индекса для этого ключа. У меня 8К-блоки, соответственно ключ может быть up to 6Кб с небольшим.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Безумно большой первичный ключ / 20 сообщений из 20, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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