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

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

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

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

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

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

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

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

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

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

Максимум, что я видел в клиентских базах это 3-4 поля суммарной длиной 40-50 в символьном представлении. Но теоретически тот же оракул позволяет создать ключ размером в 2000 (или 4?) байт. Жар-птичка - до 4096.а что не так с размером? не хватает? 0_о
а с распределением? а вам не все равно? это же суррогат
...
Рейтинг: 0 / 0
Безумно большой первичный ключ
    #36328507
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nafа что не так с размером? не хватает? 0_о
Наоборот - лишко. У меня в таблице протокола есть поле (даже два), в которые записываются значения ключей. Если эти поля слишком большие - падает производительность. Слишком маленькие - ...., ну, всем ясно. Вот, ищу баланс с помощью народного мнения.
Настройку в руки пользователя я, конечно, дам, но нужно осмысленное значение по умолчанию для тех, кто не заморачивается чтением документации и ковырянием настроек.
...
Рейтинг: 0 / 0
Безумно большой первичный ключ
    #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]