Текущее время: Чт, мар 28 2024, 12:40

Часовой пояс: 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 часа


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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