Текущее время: Пт, мар 29 2024, 00:24

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
 Заголовок сообщения: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пт, май 18 2018, 17:09 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Насколько мне известно, для полей, хранящих целочисленные неотрицательные значения и входящих в первичный ключ прозрачной таблицы, рекомендуется использовать не какой-то из типов INT*, а NUMC. Однако что-то не могу найти, что пишет САП на эту тему. Возможно, это устаревшие рекомендации, или же СУБД-зависимые, или же я ошибаюсь.

Подскажите, пожалуйста:
1. Есть ли у САП рекомендации, какой тип и в каких случаях лучше использовать для поля первичного ключа, хранящего целочисленные неотрицательные значения? И если есть – то какие?
2. Какие преимущества и недостатки при использовании для поля первичного ключа типа NUMC, по сравнению с использованием INT*?

Из того, что нашел по 2-у вопросу:
Преимущества NUMC:
1. При добавлении записей в запрос (объект TABU) можно указывать только значения ключевых полей, стоящих до INT*-поля.
2. Может быть использовано для записи бОльших значений
3. Удобнее для выполнения строковых операций (конкатенация и т.д.)
4. Удобнее для работы с экранными полями
Недостатки NUMC:
1. Следует не забывать о ведущих нулях
2. В поле могут быть записаны не только числа


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пт, май 18 2018, 18:01 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Вт, сен 05 2017, 23:56
Сообщения: 537
Code:
2. Какие преимущества и недостатки при использовании для поля первичного ключа типа NUMC, по сравнению с использованием INT*?

INT немного быстрее и меньше места ест. Так как NUMC это всё таки строковый и хранится в СУБД как строка


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Сб, май 19 2018, 10:08 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Чт, ноя 11 2004, 16:25
Сообщения: 3109
Пол: Мужской
LAT написал(а):
Насколько мне известно, для полей, хранящих целочисленные неотрицательные значения и входящих в первичный ключ прозрачной таблицы, рекомендуется использовать не какой-то из типов INT*, а NUMC. Однако что-то не могу найти, что пишет САП на эту тему. Возможно, это устаревшие рекомендации, или же СУБД-зависимые, или же я ошибаюсь.

Подскажите, пожалуйста:
1. Есть ли у САП рекомендации, какой тип и в каких случаях лучше использовать для поля первичного ключа, хранящего целочисленные неотрицательные значения? И если есть – то какие?
2. Какие преимущества и недостатки при использовании для поля первичного ключа типа NUMC, по сравнению с использованием INT*?

Из того, что нашел по 2-у вопросу:
Преимущества NUMC:
1. При добавлении записей в запрос (объект TABU) можно указывать только значения ключевых полей, стоящих до INT*-поля.
2. Может быть использовано для записи бОльших значений
3. Удобнее для выполнения строковых операций (конкатенация и т.д.)
4. Удобнее для работы с экранными полями
Недостатки NUMC:
1. Следует не забывать о ведущих нулях
2. В поле могут быть записаны не только числа

Конкретных рекомендаций не помню.
Все таки, это зависит от задачи. У Вас смысловая нагрузка этого поля в чем заключается? Что с ним надо будет делать дальше? В общем случае это NUMC/CHAR. (Если надо различать значения 1 и 01 то только CHAR)
В целом, даже и не могу сходу вспомнить ситуаций когда в ключе понадобилось бы использовать обязательно INT.
По стандарту тоже, номера объектов, номера позиций, во многом char/numc
Недостатки NUMC:
1. Следует не забывать о ведущих нулях ---- используйте подпрограмму преобразования
2. В поле могут быть записаны не только числа ---- а что еще?

Если с точки зрения numc как числа, то:
По NUMC нельзя проводить вычисления
По NUMC соответственно ограничен в select в определенных функциях
А это надо в случае если поле в ключе?

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пн, май 21 2018, 14:25 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Besa написал:
Все таки, это зависит от задачи. У Вас смысловая нагрузка этого поля в чем заключается?
Счетчик. Чтобы различать данные с одинаковым ИД, обработанные в одно и то же время.
Besa написал:
В общем случае это NUMC/CHAR.
Только не CHAR. :)
Besa написал:
2. В поле могут быть записаны не только числа ---- а что еще?
Данные типа char. Например, создаем таблицу zlat_test_05 с полями mandt и numc типа numc(5) и код:
Code:
DATA: BEGIN OF char,
        mandt TYPE sy-mandt,
        numc TYPE c LENGTH 5,
      END OF char.
char-numc = 'ёклмн'.
INSERT zlat_test_05 FROM char.

Besa написал:
По NUMC нельзя проводить вычисления
Имеется в виду: прямо в селекте?
Besa написал:
Повторюсь преимущества и недостатки зависят от условий и нюансов задачи.
Да. Я просто откуда-то был уверен, что у САП существуют какие-то общие рекомендации.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пн, май 21 2018, 14:37 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Чт, ноя 11 2004, 16:25
Сообщения: 3109
Пол: Мужской
LAT написал(а):
Besa написал:
Все таки, это зависит от задачи. У Вас смысловая нагрузка этого поля в чем заключается?
Счетчик. Чтобы различать данные с одинаковым ИД, обработанные в одно и то же время.

А можно по подробнее? :) Все таки я лучше постараюсь дать совет исходя из цели.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пн, май 21 2018, 17:16 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Besa написал:
А можно по подробнее?
Вопрос уже представляет интерес, безотносительно задачи, в рамках которой он возник :).
Что касается самой задачи. Если подробно, описывать придется очень много, поэтому делаю пересказ в очень упрощенном виде. Из внешней системы приходят данные, которые должны быть заведены в САП. После каждой обработки – коммит («спасибо» стандартному ФМ-у) и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом. Структура таблицы формировалась, исходя из железобетонной уверенности, что за 1 сеанс связи по каждому ИД может быть получено не более 1 набора данных (внешняя система просто физически не может прислать больше 1 набора данных). Поэтому был сделан выбор в пользу естественных ключей. Когда таблица достаточно налилась данными на продуктиве, внезапно оказалось, что:
1) перед обработкой данные нужно забуферизировать в еще 1 Z-таблице САП, а уж из буфера могут одновременно браться для обработки и несколько наборов для одного и того же ИД
2) в ближайшем будущем из 1 набора данных внешней системы надо будет формировать несколько наборов, которые нужно завести в САП
Т.е. суть проблемы в том, что текущая структура таблицы лога не позволяет выполнять запись информации о массовой обработке.
Понятно, что эту задачу можно решить разными способами: переделкой алгоритма, чтобы информация об обработке набора не писалась сразу после обработки набора в лог, а группировалась по ИД и записывалась в лог после обработки всех наборов; увеличением значения поля «время обработки» перед записью в лог; добавления в ключ микросекунд; формированием отдельного ИД обработки… Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог :).


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пн, май 21 2018, 17:57 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Чт, ноя 11 2004, 16:25
Сообщения: 3109
Пол: Мужской
LAT написал(а):
Besa написал:
А можно по подробнее?
Вопрос уже представляет интерес, безотносительно задачи, в рамках которой он возник :).
Что касается самой задачи. Если подробно, описывать придется очень много, поэтому делаю пересказ в очень упрощенном виде. Из внешней системы приходят данные, которые должны быть заведены в САП. После каждой обработки – коммит («спасибо» стандартному ФМ-у) и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом. Структура таблицы формировалась, исходя из железобетонной уверенности, что за 1 сеанс связи по каждому ИД может быть получено не более 1 набора данных (внешняя система просто физически не может прислать больше 1 набора данных). Поэтому был сделан выбор в пользу естественных ключей. Когда таблица достаточно налилась данными на продуктиве, внезапно оказалось, что:
1) перед обработкой данные нужно забуферизировать в еще 1 Z-таблице САП, а уж из буфера могут одновременно браться для обработки и несколько наборов для одного и того же ИД
2) в ближайшем будущем из 1 набора данных внешней системы надо будет формировать несколько наборов, которые нужно завести в САП
Т.е. суть проблемы в том, что текущая структура таблицы лога не позволяет выполнять запись информации о массовой обработке.
Понятно, что эту задачу можно решить разными способами: переделкой алгоритма, чтобы информация об обработке набора не писалась сразу после обработки набора в лог, а группировалась по ИД и записывалась в лог после обработки всех наборов; увеличением значения поля «время обработки» перед записью в лог; добавления в ключ микросекунд; формированием отдельного ИД обработки… Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог :).

Да, зря я спросил :lol: Возможно имеет смысл пересмотреть логику, для меня показалось сумбурно.
В общем случае это делается так - поле тип CHAR10(например), создаете счетчик через SNRO с ДИ что то вроде 1000000000-9999999999, перед insert-ом получаете номер(через спец ФМ) и постите запись.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Пн, май 21 2018, 18:24 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Этот вариант рассматривался под формулировкой "формирование отдельного ИД обработки". Только, имхо, char ни в коем случае нельзя использовать как поле ключа для хранения целых неотрицательных значений.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Вт, май 22 2018, 15:51 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, мар 29 2007, 11:51
Сообщения: 330
Откуда: Yugorsk.RU
Пол: Мужской
Цитата:
и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом


Для высоконагруженных логов имхо лучше использовать первичный ключ из единственного поля, который хранит TIMESTAMP (с микросекундами). Использование дата-время чревато, т.к. шаг = 1 секунда, в приличной системе за 1 секунду можно много чего напихать.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Ср, май 23 2018, 11:53 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
pberezin написал:
Цитата:
и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом


Для высоконагруженных логов имхо лучше использовать первичный ключ из единственного поля, который хранит TIMESTAMP (с микросекундами). Использование дата-время чревато, т.к. шаг = 1 секунда, в приличной системе за 1 секунду можно много чего напихать.

для высоконагруженных логов лучше не писать в бд если на то пошло

не надо изобретать велосипеды на костылях. есть BAL_LOG см. тр. SLG1

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Ср, май 23 2018, 16:07 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3074
Откуда: Москва
LAT написал(а):
Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог :).

BC414, глава Number Range Assigment :rtfm:

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Ср, май 23 2018, 16:46 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Удав написал(а):
LAT написал(а):
Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог :).
BC414, глава Number Range Assigment :rtfm:
Для диапазонов номеров действительно указано: "domain can be either type NUMC or type CHAR and can have a field length of up to 20 characters". О полях ключа для хранения числовых значений не сказано ничего. Но вполне возможно, что мои [судя по всему, неправильные] представления о желательности использовании для целочисленных полей ключа типа NUMC взялись именно отсюда.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Ср, май 23 2018, 17:42 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3074
Откуда: Москва
LAT написал(а):
Но вполне возможно, что мои [судя по всему, неправильные] представления о желательности использовании для целочисленных полей ключа типа NUMC взялись именно отсюда.

1. Почему неправильные?
2. Нужно учитывать, что оператор COLLECT суммирует все числовые поля, если таблица не типа sorted с явным указанием ключевых полей.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Первичный ключ и целые неотрицательные значения
СообщениеДобавлено: Ср, май 23 2018, 18:36 
Старший специалист
Старший специалист

Зарегистрирован:
Чт, май 12 2011, 16:06
Сообщения: 347
Удав написал(а):
LAT написал(а):
Но вполне возможно, что мои [судя по всему, неправильные] представления о желательности использовании для целочисленных полей ключа типа NUMC взялись именно отсюда.
1. Почему неправильные?
Судя по данному обсуждению, таких советов САП не дает.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB