SAPфорум.RU https://www.sapboard.ru/forum/ |
|
Первичный ключ и целые неотрицательные значения https://www.sapboard.ru/forum/viewtopic.php?f=13&t=96412 |
Страница 1 из 1 |
Автор: | LAT [ Пт, май 18 2018, 17:09 ] |
Заголовок сообщения: | Первичный ключ и целые неотрицательные значения |
Насколько мне известно, для полей, хранящих целочисленные неотрицательные значения и входящих в первичный ключ прозрачной таблицы, рекомендуется использовать не какой-то из типов INT*, а NUMC. Однако что-то не могу найти, что пишет САП на эту тему. Возможно, это устаревшие рекомендации, или же СУБД-зависимые, или же я ошибаюсь. Подскажите, пожалуйста: 1. Есть ли у САП рекомендации, какой тип и в каких случаях лучше использовать для поля первичного ключа, хранящего целочисленные неотрицательные значения? И если есть – то какие? 2. Какие преимущества и недостатки при использовании для поля первичного ключа типа NUMC, по сравнению с использованием INT*? Из того, что нашел по 2-у вопросу: Преимущества NUMC: 1. При добавлении записей в запрос (объект TABU) можно указывать только значения ключевых полей, стоящих до INT*-поля. 2. Может быть использовано для записи бОльших значений 3. Удобнее для выполнения строковых операций (конкатенация и т.д.) 4. Удобнее для работы с экранными полями Недостатки NUMC: 1. Следует не забывать о ведущих нулях 2. В поле могут быть записаны не только числа |
Автор: | Kuranov.Dmitry [ Пт, май 18 2018, 18:01 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Code: 2. Какие преимущества и недостатки при использовании для поля первичного ключа типа NUMC, по сравнению с использованием INT*? INT немного быстрее и меньше места ест. Так как NUMC это всё таки строковый и хранится в СУБД как строка |
Автор: | Besa [ Сб, май 19 2018, 10:08 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
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 в определенных функциях А это надо в случае если поле в ключе? Повторюсь преимущества и недостатки зависят от условий и нюансов задачи. |
Автор: | LAT [ Пн, май 21 2018, 14:25 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
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 написал: Повторюсь преимущества и недостатки зависят от условий и нюансов задачи. Да. Я просто откуда-то был уверен, что у САП существуют какие-то общие рекомендации.
|
Автор: | Besa [ Пн, май 21 2018, 14:37 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
LAT написал(а): Besa написал: Все таки, это зависит от задачи. У Вас смысловая нагрузка этого поля в чем заключается? Счетчик. Чтобы различать данные с одинаковым ИД, обработанные в одно и то же время.А можно по подробнее? Все таки я лучше постараюсь дать совет исходя из цели. |
Автор: | LAT [ Пн, май 21 2018, 17:16 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Besa написал: А можно по подробнее? Вопрос уже представляет интерес, безотносительно задачи, в рамках которой он возник .Что касается самой задачи. Если подробно, описывать придется очень много, поэтому делаю пересказ в очень упрощенном виде. Из внешней системы приходят данные, которые должны быть заведены в САП. После каждой обработки – коммит («спасибо» стандартному ФМ-у) и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом. Структура таблицы формировалась, исходя из железобетонной уверенности, что за 1 сеанс связи по каждому ИД может быть получено не более 1 набора данных (внешняя система просто физически не может прислать больше 1 набора данных). Поэтому был сделан выбор в пользу естественных ключей. Когда таблица достаточно налилась данными на продуктиве, внезапно оказалось, что: 1) перед обработкой данные нужно забуферизировать в еще 1 Z-таблице САП, а уж из буфера могут одновременно браться для обработки и несколько наборов для одного и того же ИД 2) в ближайшем будущем из 1 набора данных внешней системы надо будет формировать несколько наборов, которые нужно завести в САП Т.е. суть проблемы в том, что текущая структура таблицы лога не позволяет выполнять запись информации о массовой обработке. Понятно, что эту задачу можно решить разными способами: переделкой алгоритма, чтобы информация об обработке набора не писалась сразу после обработки набора в лог, а группировалась по ИД и записывалась в лог после обработки всех наборов; увеличением значения поля «время обработки» перед записью в лог; добавления в ключ микросекунд; формированием отдельного ИД обработки… Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог . |
Автор: | Besa [ Пн, май 21 2018, 17:57 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
LAT написал(а): Besa написал: А можно по подробнее? Вопрос уже представляет интерес, безотносительно задачи, в рамках которой он возник .Что касается самой задачи. Если подробно, описывать придется очень много, поэтому делаю пересказ в очень упрощенном виде. Из внешней системы приходят данные, которые должны быть заведены в САП. После каждой обработки – коммит («спасибо» стандартному ФМ-у) и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом. Структура таблицы формировалась, исходя из железобетонной уверенности, что за 1 сеанс связи по каждому ИД может быть получено не более 1 набора данных (внешняя система просто физически не может прислать больше 1 набора данных). Поэтому был сделан выбор в пользу естественных ключей. Когда таблица достаточно налилась данными на продуктиве, внезапно оказалось, что: 1) перед обработкой данные нужно забуферизировать в еще 1 Z-таблице САП, а уж из буфера могут одновременно браться для обработки и несколько наборов для одного и того же ИД 2) в ближайшем будущем из 1 набора данных внешней системы надо будет формировать несколько наборов, которые нужно завести в САП Т.е. суть проблемы в том, что текущая структура таблицы лога не позволяет выполнять запись информации о массовой обработке. Понятно, что эту задачу можно решить разными способами: переделкой алгоритма, чтобы информация об обработке набора не писалась сразу после обработки набора в лог, а группировалась по ИД и записывалась в лог после обработки всех наборов; увеличением значения поля «время обработки» перед записью в лог; добавления в ключ микросекунд; формированием отдельного ИД обработки… Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог . Да, зря я спросил Возможно имеет смысл пересмотреть логику, для меня показалось сумбурно. В общем случае это делается так - поле тип CHAR10(например), создаете счетчик через SNRO с ДИ что то вроде 1000000000-9999999999, перед insert-ом получаете номер(через спец ФМ) и постите запись. |
Автор: | LAT [ Пн, май 21 2018, 18:24 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Этот вариант рассматривался под формулировкой "формирование отдельного ИД обработки". Только, имхо, char ни в коем случае нельзя использовать как поле ключа для хранения целых неотрицательных значений. |
Автор: | pberezin [ Вт, май 22 2018, 15:51 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Цитата: и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом Для высоконагруженных логов имхо лучше использовать первичный ключ из единственного поля, который хранит TIMESTAMP (с микросекундами). Использование дата-время чревато, т.к. шаг = 1 секунда, в приличной системе за 1 секунду можно много чего напихать. |
Автор: | Kengur [ Ср, май 23 2018, 11:53 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
pberezin написал: Цитата: и запись в лог (Z-таблица вида {ИД из внешней системы; дата обработки; время обработки; информация об обработке}, ключ - ИД, дата, время) с коммитом Для высоконагруженных логов имхо лучше использовать первичный ключ из единственного поля, который хранит TIMESTAMP (с микросекундами). Использование дата-время чревато, т.к. шаг = 1 секунда, в приличной системе за 1 секунду можно много чего напихать. для высоконагруженных логов лучше не писать в бд если на то пошло не надо изобретать велосипеды на костылях. есть BAL_LOG см. тр. SLG1 |
Автор: | Удав [ Ср, май 23 2018, 16:07 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
LAT написал(а): Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог . BC414, глава Number Range Assigment |
Автор: | LAT [ Ср, май 23 2018, 16:46 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Удав написал(а): LAT написал(а): Но выбор был сделан в пользу добавления в ключ числового поля («счетчика»), которое бы было сквозным для всех ИД и увеличивалось на 1 перед записью в лог (т.е. физического смысла это поле не несет). Имхо, INT4 достаточно. В этот момент я вспомнил о совете использовать для числовых ключей тип NUMC, а вот откуда взялся этот совет, я вспомнить уже не смог . BC414, глава Number Range Assigment |
Автор: | Удав [ Ср, май 23 2018, 17:42 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
LAT написал(а): Но вполне возможно, что мои [судя по всему, неправильные] представления о желательности использовании для целочисленных полей ключа типа NUMC взялись именно отсюда. 1. Почему неправильные? 2. Нужно учитывать, что оператор COLLECT суммирует все числовые поля, если таблица не типа sorted с явным указанием ключевых полей. |
Автор: | LAT [ Ср, май 23 2018, 18:36 ] |
Заголовок сообщения: | Re: Первичный ключ и целые неотрицательные значения |
Удав написал(а): LAT написал(а): Но вполне возможно, что мои [судя по всему, неправильные] представления о желательности использовании для целочисленных полей ключа типа NUMC взялись именно отсюда. 1. Почему неправильные? |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |