您并没有真正提供有关您要更新的内容等的很多详细信息。
作为编写更新语句的基础,除非您无法在 SQL 中实现您想要做的事情,否则不要使用 PL/SQL,因为在您开始处理任何记录之前,单独的上下文切换会损害您的性能。
如果您能够专门为更新创建索引,则索引将出现在更新语句WHERE
子句中的列,以便在更新之前快速找到记录。
至于插入,请查看/*+ append */
插入记录提示的好处,看看它是否有利于您的特定情况。
最后,您将使用的表结构将取决于您甚至还没有开始接触您提供的详细信息的可能因素,我建议您要么对 DB 结构进行一些研究,要么向您的 DBA 询问 101 课程它。
祝你好运...
编辑:
回应:
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 )
将 PRIMARY KEY 作为 VARCHAR2 数据类型没有任何问题(尽管经常争论具有非特定 PK 的值,即序列)。但是,您必须确保您的 PK 是唯一的,如果您不能保证这一点,那么值得将序列作为您的 PK,而不是必须引入另一个列来保持唯一性。
至于将表列声明为 INTEGER,它们最终将被解析为 NUMBER,因此我只需将表列创建为数字(除非您有非常具体的原因将它们创建为 INTEGER)。
最后,对于 DATETIME 列,您只需要将其作为 DATE 数据类型进行处理,除非您的时间部分需要真正的精度,在这种情况下,将其声明为 TIMESTAMP 数据类型。
至于帮助您处理表格本身的结构(即您想要哪些列等)那不是我可以帮助您的,因为我对您的报告要求、申请要求或审计要求、公司最佳实践、命名一无所知公约等。恐怕这是你自己决定的事情。
但是,为了性能,将索引保持在最小值(即仅有助于您的 UPDATE WHERE 子句搜索的索引列),仅更新可能的最少数据,并且如前所述,研究插入的 APPEND 提示,它可能对您的情况有所帮助,但您将不得不自己测试它。