Currently we do not save the output to a database. This functionality was removed because the identity file was undergoing some radical changes. But there is a workaround (this actual works better if you are trying to interrogate the OYSTER output for downstream work). If you're input data resides in a database use the OysterDatabaseReader to create/update your identity file. After each run load the link file into a look up table. You will need to do some light ETL on the link file as you load it. It is a simple tab delimited file that contains the RefID and the OysterID. The RefID is a period delimited element it contains the source name and the ID from your database table. The reason for the source name is to make this id unique. This is needed because most ID are just incremental numerics. You would probably want to split this into two separate fields as it will make the database join cleaner. Once you have the file loaded and indexed you can simple do a join back to the original table.
One thing that is needed that will be forthcoming in Version 3.3 is capturing any changes to OYSTER IDs because of merging when updating the identity file. This merge map would also have to be loaded and reconciled so that you can track you historical changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can we pass the identity ouput to a database table?
Kumar
Currently we do not save the output to a database. This functionality was removed because the identity file was undergoing some radical changes. But there is a workaround (this actual works better if you are trying to interrogate the OYSTER output for downstream work). If you're input data resides in a database use the OysterDatabaseReader to create/update your identity file. After each run load the link file into a look up table. You will need to do some light ETL on the link file as you load it. It is a simple tab delimited file that contains the RefID and the OysterID. The RefID is a period delimited element it contains the source name and the ID from your database table. The reason for the source name is to make this id unique. This is needed because most ID are just incremental numerics. You would probably want to split this into two separate fields as it will make the database join cleaner. Once you have the file loaded and indexed you can simple do a join back to the original table.
One thing that is needed that will be forthcoming in Version 3.3 is capturing any changes to OYSTER IDs because of merging when updating the identity file. This merge map would also have to be loaded and reconciled so that you can track you historical changes.