When the PRPC schema was created, the tables are normalized by the DBA so that the work objects and attachments are stored in separate tables to have optimal performance and storagemanagement.
The attachments are of different types such as files, screenshots etc. Each of them may have different storage requirements. Hence, it is always better to store them separately from the corresponding work objects to address the storage management, searching, partitioning of table etc.
Thank you for your reply. I have an addtional query about the retrieving the attachments. when we open work object that has attachment, we can open the attachments. However, how does PRPC retrieves the attachments separately when they are in a table in PRPC database or external database?
When you try to open PEGA case attachments it queries the Link-Attachment table with the pega case and brings the list of attachments for that case in the user page "AttachmentList". Each link attachments specifies the property "pxLinkedRefTo" which contains the class and key of the real attachment. This class present in the first part of "pxLinkedRefTo" determines the Database table.
Thank you for your reply. I have one more scenario in which there are a number of records in an excel sheet, and there are corrresponding PDF files for each records in the excel sheet. The PDF files are stored in a directory. I would like to store the records and corresponding PDF files in a PRPC table, and be able to search and view or retrieve (download) from UI. Would you or anyone share the way we can achieve this. I appreciatefurther thoughts.
Please also note: PRPC can store attachments completely separately (in a Content Management System for instance) from the Work Items - its just the default behaviour to use a separate 'internal' Attachment DB table for this purpose.
Also : to answer your original question - it makes sense to store attachments in a separate table from Work Items : not least because there is a one-to-many realtionship between Work Items and Attachments.
That is: A single Work Item may (and usually does) have many attachments; it wouldn't be flexible to keep opening up the Work Item Record, adding in a new Binary BLOBs (to represent the attachment data) and then re-saving the work item ; or (say) having a separate (but limited number of) columns for each Attachment.