URGENT: Risks of SPDS elimination

[deleted_user]

Hi,

We are using SPDS on UNIX in one of the BI application for doing ETL operations. As per the system admin, SPDS needs separate license (other than Base SAS license) that requires additional funds. I don’t have much information of the advantages of SPDS except the performance and data handling. We don’t have any requirement of improving the performance and space utilization at the cost of SPDS license.
So based upon this we are thinking to remove SPDS from our application.
Please suggest your views on this and what may the probable risk for SPDS elimination.

[Peter_C]

if it does not justify itself, then you will find it hard to keep paying the licence fees.

very quickly, you must find out the cost/performance impact of not having SPDS!

To assess the performance cost of not using SPDS, try some of your processes using an alternate data platform. SAS/Access to some alternate rdbms (perhaps your administrators recommend/demand their site standard rdbms) will still need/cost a SAS licence fee, but you may already be paying for that. It is well worth trying the conversion and separately measure any performance penalty.

Don't ignore the possibility that base SAS data sets may meet your needs.
In use, the performance of base SAS data sets is very different from the performance of SPDS tables, and don't support (iirc) the access control lists some sites use on SPDS.

A halfway house for performance is the SAS SPD library engine. This is available within the base SAS9 licence. For larger data sets, SPDE provides considerable performance improvements (imho) over base SAS data sets, because it uses data partitioning and more sophisticated index engines.

Usually the message is you pay your money and make your choice, but ensure you appreciate what you are paying licence fees for ~ and make budget managers aware also.

If you need help with it, I'm sure that your SAS sales executive would be keen to help you make the case for keeping SPDS.


good luck
PeterC

[LinusH]

Besides from performance, one could reflect on the following features of SODS:
-As Peter mentioned, authorization, as well as authentication is a part of the software. If your application restriction in data access, you need to perform these tasks at the OS level instead (or in an external RDBMS). Be aware of that you can't put authorization on a column/row level in the OS.
-Built in backup/restore routines allow you do incremental backup. With Base/SPDE tables you need to do full backup.
-Row level locking comes with SPDS. SHARE has it as well, but with significant lower performance, especially during batch load.
-Centralized servers. Means that you can easily close down user access to perform DBA work, backup/restore. Otherwise you may have to do some "kill" on pid's in the OS environment.

Whether it's worth it or not is up to you to find out.

Regards,
Linus