Вы не очень подробно рассказали, ЧТО вы обновляете и т. Д.
В качестве основы для написания операторов обновления не используйте PL / SQL, если только вы не можете достичь того, что вы хотите сделать в SQL, поскольку только переключение контекста ухудшит вашу производительность, прежде чем вы даже приступите к обработке любых записей. .
Если вы можете создавать индексы специально для обновления, то индексируйте столбцы, которые появятся в предложении WHERE вашего оператора обновления, чтобы записи можно было быстро найти перед обновлением.
Что касается вставки, посмотрите преимущества подсказки /*+ append */ для вставки записей, чтобы увидеть, пойдет ли она на пользу вашему конкретному случаю.
Наконец, структура таблицы, которую вы будете использовать, будет зависеть от тех факторов, которые вы даже не начали касаться с предоставленными вами деталями. Я предлагаю вам либо провести некоторое исследование структуры БД, либо попросить ваших администраторов баз данных 101 класс в нем.
Удачи ...
EDIT:
В ответ на:
Play ID - ID ( here id would be song name like abc.wav something..so may be VARCHAR2, yet not decided..whats your openion...is that fine if primary key is of type VARCHAR2....any suggesstions are most welcome...... ) Type - Song or Message ( varchar2) Count - Summation of total play ( Integer) Retries - Summation of total play, if failed. ( Integer) Duration - Total Duration ( Integer) Last Updated - Late Updated Date Time ( DateTime )
Нет ничего плохого в том, что в качестве типа данных VARCHAR2 используется ПЕРВИЧНЫЙ КЛЮЧ (хотя часто возникают споры о значении наличия неспецифического PK, то есть последовательности). Однако вы должны убедиться, что ваш PK уникален, и если вы не можете это гарантировать, то вам стоит иметь такую последовательность, как ваш PK, вместо того, чтобы вводить другой столбец для сохранения уникальности.
Что касается объявления ваших столбцов таблицы как INTEGER, они в конечном итоге все равно будут преобразованы в NUMBER, так что я бы просто создал столбец таблицы как число (если у вас нет особых причин для их создания как INTEGER).
Наконец, для столбца DATETIME вам нужно только уменьшить его как тип данных DATE, если только вам не нужна реальная точность в вашей временной части, в этом случае объявите его как тип данных TIMESTAMP.
Что касается помощи вам в структуре самой таблицы (то есть, какие столбцы вы хотите и т. Д.), Тогда я не могу вам помочь, поскольку ничего не знаю о ваших требованиях к отчетности, требованиях к приложениям или требованиям аудита, лучше всего компании практика, правила именования и т. д. Боюсь, это то, что вы решите сами.
Для повышения производительности сохраняйте индексы минимальными (т. Е. Только столбцы индексов, которые помогут при поиске предложения UPDATE WHERE), обновляйте только минимально возможные данные и, как предлагалось ранее, изучите подсказку APPEND для вставок, которые могут помочь в вашем случае, но вам придется проверить это для себя.