Comment Relational DB required? (Score 1) 47
My experience only covers the big RDBMSs: DB2, Oracle, Sybase, Informix, etc.
Overall:
None offer full SQL implementations. None offer clean programming constructs within SQL. None offer the ability to drive system+IO functionality from within a non3GL-API environment (their forms tools partially excepted).
Specifically:
* Informix is a barely visible wrapper round I/VSAM.
* Sybase is functionally equivalent to Oracle but has BADLY buggy SQL. If you are restricted to Sybase and want usable SQL, I advise driving it via SAS without passthru.
* Oracle does not have the jawdropping bugs of Sybase but has equivalent design/structure: it is NOT relational despite its advertising. It offers some relational sounding words but does not support correct consistency, integrity, etc. For example, to support transactions (OFF by default)(no, the ability to Commit data is not the same as Transactions), the DBMSs locking granularity is one table... Unbelievable. ie you can not practically establish a maximum level of data corruption risk in a multiuser environment.
However, since most selfprofessed RDBMS coders are simply manipulating data via APIs, they are really just buying ISAM plus a DDL and a couple of DML macros. In which case get whichever DBMS runs quicker, use your 3GL of choice, and just accept the high code/maintenance costs.
Other:
* DB2 was relational and used to get the thumbsup all round but have no idea where it is nowadays.
* A friend has said good things about PostGreSQL, principally comparing it to MSAccess, but it seems to offer full SQL.
* Re the speed comments on other posts here: realistically, minor processing time differences will seem slight for a nonmajor site, compared to the time spent downloading graphics etc.: I'd strongly suggest you go with ease of use rather than try to squeeze out an extra 0.1 second. Optimising TPS is usually a splendid way to waste spectacular amounts of time and money.
Good luck!
Overall:
None offer full SQL implementations. None offer clean programming constructs within SQL. None offer the ability to drive system+IO functionality from within a non3GL-API environment (their forms tools partially excepted).
Specifically:
* Informix is a barely visible wrapper round I/VSAM.
* Sybase is functionally equivalent to Oracle but has BADLY buggy SQL. If you are restricted to Sybase and want usable SQL, I advise driving it via SAS without passthru.
* Oracle does not have the jawdropping bugs of Sybase but has equivalent design/structure: it is NOT relational despite its advertising. It offers some relational sounding words but does not support correct consistency, integrity, etc. For example, to support transactions (OFF by default)(no, the ability to Commit data is not the same as Transactions), the DBMSs locking granularity is one table... Unbelievable. ie you can not practically establish a maximum level of data corruption risk in a multiuser environment.
However, since most selfprofessed RDBMS coders are simply manipulating data via APIs, they are really just buying ISAM plus a DDL and a couple of DML macros. In which case get whichever DBMS runs quicker, use your 3GL of choice, and just accept the high code/maintenance costs.
Other:
* DB2 was relational and used to get the thumbsup all round but have no idea where it is nowadays.
* A friend has said good things about PostGreSQL, principally comparing it to MSAccess, but it seems to offer full SQL.
* Re the speed comments on other posts here: realistically, minor processing time differences will seem slight for a nonmajor site, compared to the time spent downloading graphics etc.: I'd strongly suggest you go with ease of use rather than try to squeeze out an extra 0.1 second. Optimising TPS is usually a splendid way to waste spectacular amounts of time and money.
Good luck!
