ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Вопросы по проектированию таблицы
15 сообщений из 15, страница 1 из 1
Вопросы по проектированию таблицы
    #38733986
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Есть два альтернативных вариант создания таблицы.
Вариант 1 (с суррогатным ключом)
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
CREATE TABLE public.table1 (
  id SERIAL,
  field1 BIGINT NOT NULL,
  field2 TEXT NOT NULL,
  CONSTRAINT table1_idx UNIQUE(field1, field2),
  CONSTRAINT table1_pkey PRIMARY KEY(id)
) 
WITH (oids = false);



Вариант 2 (без суррогатного ключа)
Код: sql
1.
2.
3.
4.
5.
6.
CREATE TABLE public.table1 (
  field1 BIGINT NOT NULL,
  field2 TEXT NOT NULL,
  CONSTRAINT table1_pkey PRIMARY KEY(field1, field2)
) 
WITH (oids = false);



Какой вариант предпочтительней с точки зрения производительности по операциям выборки, обновления, удаления и вставки.
предполагаемый объем данных ~ 2 млн. записей.
примерная нагрузка - одна операция в минуту.
Спасибо.
...
Рейтинг: 0 / 0
01.09.2014, 12:37:19
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734142
daevy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
daevy
Гость
big-trot,

поле id оправдано если оно несет какую-то смысловую нагрузку (product_id, article_id, author_id) и явно используется в выборках. а если нет, то его можно убрать. читайте подробности в "Программирование баз данных" Карвина (4 глава вроде).
...
Рейтинг: 0 / 0
01.09.2014, 15:19:15
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734222
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
"суррогатный ключ" - это такой адовый халевар, покруче "майсикуель vs постгрес", так он на все времена и базы)

лучше, делайте сурогат всегда!

но если он вам пока не нужен, не вешайте на него индекс, сэкономите места
...
Рейтинг: 0 / 0
01.09.2014, 16:25:21
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734241
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
big-trotЕсть два альтернативных вариант создания таблицы.
Вариант 1 (с суррогатным ключом)
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
CREATE TABLE public.table1 (
  id SERIAL,
  field1 BIGINT NOT NULL,
  field2 TEXT NOT NULL,
  CONSTRAINT table1_idx UNIQUE(field1, field2),
  CONSTRAINT table1_pkey PRIMARY KEY(id)
) 
WITH (oids = false);



Вариант 2 (без суррогатного ключа)
Код: sql
1.
2.
3.
4.
5.
6.
CREATE TABLE public.table1 (
  field1 BIGINT NOT NULL,
  field2 TEXT NOT NULL,
  CONSTRAINT table1_pkey PRIMARY KEY(field1, field2)
) 
WITH (oids = false);



Какой вариант предпочтительней с точки зрения производительности по операциям выборки, обновления, удаления и вставки.
предполагаемый объем данных ~ 2 млн. записей.
примерная нагрузка - одна операция в минуту.
Спасибо.

у вас явно это промежуточная таблица для связи many to many
в них суррогатный ключ не только вреден но еще и бесполезен...

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
01.09.2014, 16:50:29
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734320
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Maxim Boguk,

бигинт и текст -- возможно это теги или еще какая детализация.

если челове сомневается, то возможно у него какие-то уже в уме способы доступа к этому дело есть. пусть расскажет
...
Рейтинг: 0 / 0
01.09.2014, 18:08:47
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734416
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Misha Tyurin бигинт и текст -- возможно это теги или еще какая детализация.

бигинт - это идентификатор продукции
текст - это заводской номер изделия

в сочетании с предприятием производителем это есть уникальное значение.

Но меня тревожит, что такое сочетание будет слишком грамоздким для индекса и это повлияет на производительность, особенно беспокоит поле с типом TEXT. Поэтому и возникли мысли в пользу суррогатного ключа. Суррогатный ключ будет использоваться только в операциях обновления и удаления, в выборках он, естественно, использоваться не будет.
...
Рейтинг: 0 / 0
01.09.2014, 22:02:59
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734420
/\/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
/\/\/\/\/\/\/\
Гость
big-trot,

Суррогатный ключ служит для ссылки на строку. С этим полем проблем не будет: только займет чуть места на само поле и его индекс. По полю bigint проблем тоже не будет. А вот с текстовым полем возможны варианты. Причем эти варианты на стороне разработчика, технических проблемы проявятся гораздо позже. Одно приведение к одному регистру чего стоит.

big-trot
бигинт - это идентификатор продукции
текст - это заводской номер изделия

в сочетании с предприятием производителем это есть уникальное значение.



Вот это явный сигнал о том, что структура таблицы продумана не до конца. Есть еще существенные пробелы. Поэтому говорить о технических ограничениях по-моему преждевременно. Нужно определиться со структурой, а потом проверять на особенности БД.

(Кстати, да. Суррогатный ключ в этом случае необходим. Это в плане разжигания мегахоливара).
...
Рейтинг: 0 / 0
01.09.2014, 22:19:50
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734581
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
/\/\/\/\/\/\/\ Вот это явный сигнал о том, что структура таблицы продумана не до конца

Структура таблицы продумана.
Если абстрагироваться от предмета, то суть вопроса заключается в том, что есть два варианта построения ключевых позиций таблицы. Один вариант - это составной ключ, при этом тип одного поля этого составного ключа - TEXT (вот это и настораживает).
Второй вариант - использовать суррогатный ключ (но сама идея суррогатного ключа, как и многим другим мне не нравиться). Вот я и спрашиваю, какие подводные камни могут быть в ходе эксплуатации, если в составе мульти ключа есть поле типа TEXT.
...
Рейтинг: 0 / 0
02.09.2014, 09:28:46
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734634
/\/\/\/\/\/\
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
/\/\/\/\/\/\
Гость
big-trot,

Лично у меня вопросы по структуре возникли:
- Появилось новое явление: предприятие-производитель. Соответственно, резко изменились кандидаты на уникальность/первичный ключ.
- скорее всего, идентификатор продукции - ссылка на вид продукции, а заводской номер в комбинации с продукцией дают уникальное значение. С большой степенью вероятности нужно будет организовывать внешнюю ссылочную целостность по полю field1. С вероятностью 95% - это индекс. Так же с вероятностью 95% нужно будет поискать продукцию по ее заводскому номеру без вида продукции. Это еще один индекс (скрее всего составной).

Наверное, Вы уже ответили на эти вопросы.


Попробуйте провести натурный эксперимент:
Создайте две таблицы: первым и вторым способом. Заполните их тестовыми данными. Затем повыбирайте-повставляйте-поизменяйте-поудаляйте. Время (ну и объем данных) померяйте. Сравните результаты. И нам потом сообщите.

Я полагаю, что время на операции по первому и второму способу будет практически равнозначным.

Ну и про суррогатные ключи: наверняка изделие из таблицы будет участвовать где-то еще. Подумайте, как в том другом объекте будет организована ссылка на таблицу с составным ключом.
...
Рейтинг: 0 / 0
02.09.2014, 10:18:26
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734773
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
big-trot,

Частично (SELECT) вопрос производительности освящен в этой публикации.
Так же в самом начале даны ссылки на другую публикацию посвященную суррогатным ключам.

Если коротенько, то:
значительной разницы в производительности между строками и числами нет;

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

Крис Дейт пишет, что не нужно в проектировании схемы руководствоваться удобством написания запросов. Если нет смысловой нагрузки у суррогатного ключа и речь только об удобстве, то не надо его добавлять.
...
Рейтинг: 0 / 0
02.09.2014, 12:14:46
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734811
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
big-trot
бигинт - это идентификатор продукции
текст - это заводской номер изделия
ЯНХНП

"идентификатор продукции" --- т.е. возможно несколько изделий, с одинаковым "идентификатором". Сталобыть это видимо "тип" (продукции) ? (или я неправ -- и изделия -- комплектуют "идентификаторы", которые суть -- сложные компаунды ?)

а вот обратно -- одному "заводской номер изделия" -- могут отвечать несколько "типов" ("идентификатор продукции") -- т.е. недревовидный (многофакторный, пересекающийся) классификатор ?


т.е. речь пока вовсе не про суррогат vs "естественный, многопольный" (и гуру цитировать рано), а про отсутствие ясной постановки ("для нас").
...
Рейтинг: 0 / 0
02.09.2014, 12:44:51
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38734994
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
big-trot
Гость
Спасибо всем.

Из всего вышесказанного можно сделать следующий вывод:

1. vyegorov значительной разницы в производительности между строками и числами нет;
, т.е. в составном ключе можно смело использовать поля типа TEXT, это никак не скажется на производительности (ссылка на статью здесь ). Конечно, при условии не использовать функции (например, приведение к верхнему регистру) для полей типа TEXT.

2. Если составной ключ имеет достаточный объем (по количеству полей), и есть зависимые таблицы от этого ключа, то в этом случае стоит задуматься о суррогатном ключе.
...
Рейтинг: 0 / 0
02.09.2014, 14:46:37
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38735073
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
big-trotСпасибо всем.

Из всего вышесказанного можно сделать следующий вывод:

1. vyegorov значительной разницы в производительности между строками и числами нет;
, т.е. в составном ключе можно смело использовать поля типа TEXT, это никак не скажется на производительности (ссылка на статью здесь ). Конечно, при условии не использовать функции (например, приведение к верхнему регистру) для полей типа TEXT.

2. Если составной ключ имеет достаточный объем (по количеству полей), и есть зависимые таблицы от этого ключа, то в этом случае стоит задуматься о суррогатном ключе.

Да где то так и есть.

PS: еще надо учитывать что вариант 1 будет где то на 30-50% раза больше на диске (и в памяти) в сумме занимать чем вариант 2.
...
Рейтинг: 0 / 0
02.09.2014, 15:26:06
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38736127
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
big-trotСпасибо всем.

Из всего вышесказанного можно сделать следующий вывод:

1. vyegorov значительной разницы в производительности между строками и числами нет;
, т.е. в составном ключе можно смело использовать поля типа TEXT, это никак не скажется на производительности (ссылка на статью здесь ). Конечно, при условии не использовать функции (например, приведение к верхнему регистру) для полей типа TEXT.

2. Если составной ключ имеет достаточный объем (по количеству полей), и есть зависимые таблицы от этого ключа, то в этом случае стоит задуматься о суррогатном ключе.
текст бывает разный, если он в страницу не влазит, это по-любому скажется на производительности.
Но по факту - 2 млн это немного, любой вариант должен работать быстро.
...
Рейтинг: 0 / 0
03.09.2014, 13:28:29
| Ответить | Цитировать | Написать  
Вопросы по проектированию таблицы
    #38736146
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
ах да, еще первое же обновление существвующегт идентификатора или серийника - уже сразу покажет что "надо было делать суррогатник"
...
Рейтинг: 0 / 0
03.09.2014, 13:40:44
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Вопросы по проектированию таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38734142&tid=1998506]:
 0ms
get settings:
 6ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 50ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 215ms
total:  370ms
созд. / загр.: 370ms
x
x
Закрыть


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