3 ms·

Here are some reasons (things I used in past): - ASM - DataGuard - FlashBack Query - RAC - PL/SQL (the worst language ever but very useful for building pac

by tlogan 10y ago

Here are some reasons (things I used in past): - ASM - DataGuard - FlashBack Query - RAC - PL/SQL (the worst language ever but very useful for building packages inside database) - Window Functions - Transparent Data Encryption - online reorg - RMAN and online backup Oracle as a company is terrible. But Oracle RDBMS is a mean machine. Do not underestimate it.

yxhuvud 10y ago
Postgres has at the very least window functions. What do you mean by online reorg? Schema changes in a transaction that doesn't block? Yeah, postgres has that too.
pjmlp 10y ago
> PL/SQL (the worst language ever but very useful for building packages inside database) Actually it is way better than the open source alternatives, but maybe my likeness for Ada makes my opinion biased
tannhaeuser 10y ago
> PL/SQL (the worst language ever but very useful for building packages inside database) I've heard that "in the database" sentence many times but never got it. PL/SQL is just another programming language VM that happens to have SQL types as native types, and syntax for SQL cursors. Other than for triggers and possibly indexed deterministic functions (both of which are inessential/questionable), you don't want your code "in the database" due to it lacking basic capabilities such as unit testing.
- cneumuel 10y ago
  There are several unit testing frameworks for PL/SQL. Code in the database encapsulates business logic, it gives you unified access from all clients. It can also be orders of magnitude faster. The presentation linked here https://thehelsinkideclaration.blogspot.co.at/2016/09/noplsql-vs-thickdb-which-one-requires.html https://thehelsinkideclaration.blogspot.co.at/2016/09/noplsq... proves that with flame graphs for a simple workload done from the app server vs. implemented in PL/SQL.
  - tannhaeuser 10y ago
    The performance argument I can accept (I've done PL/SQL coding and administered Oracle clusters years ago). But when it comes down to it, PL/SQL can possibly only benefit from lower inter-process or JDBC driver overhead vs. Java, say. I've seen PL/SQL becoming a CPU bottleneck in large real-time migration projects. To encapsulate business logic using PL/SQL, however, is crazy IMHO. Rather than coding your business logic in a mainstream language (with incomparably better staffing and tooling), you now have it in a proprietary niche language with awkward or even non-existent debugging. Also, the relational model is (or should be) the unified access at this level IMHO, rather than some ad-hoc data access layer.

by tlogan 10y ago

yxhuvud 10y ago

Postgres has at the very least window functions. What do you mean by online reorg? Schema changes in a transaction that doesn't block? Yeah, postgres has that too.

pjmlp 10y ago

> PL/SQL (the worst language ever but very useful for building packages inside database) Actually it is way better than the open source alternatives, but maybe my likeness for Ada makes my opinion biased

tannhaeuser 10y ago

> PL/SQL (the worst language ever but very useful for building packages inside database) I've heard that "in the database" sentence many times but never got it. PL/SQL is just another programming language VM that happens to have SQL types as native types, and syntax for SQL cursors. Other than for triggers and possibly indexed deterministic functions (both of which are inessential/questionable), you don't want your code "in the database" due to it lacking basic capabilities such as unit testing.

cneumuel 10y ago
There are several unit testing frameworks for PL/SQL. Code in the database encapsulates business logic, it gives you unified access from all clients. It can also be orders of magnitude faster. The presentation linked here https://thehelsinkideclaration.blogspot.co.at/2016/09/noplsql-vs-thickdb-which-one-requires.html https://thehelsinkideclaration.blogspot.co.at/2016/09/noplsq... proves that with flame graphs for a simple workload done from the app server vs. implemented in PL/SQL.
- tannhaeuser 10y ago
  The performance argument I can accept (I've done PL/SQL coding and administered Oracle clusters years ago). But when it comes down to it, PL/SQL can possibly only benefit from lower inter-process or JDBC driver overhead vs. Java, say. I've seen PL/SQL becoming a CPU bottleneck in large real-time migration projects. To encapsulate business logic using PL/SQL, however, is crazy IMHO. Rather than coding your business logic in a mainstream language (with incomparably better staffing and tooling), you now have it in a proprietary niche language with awkward or even non-existent debugging. Also, the relational model is (or should be) the unified access at this level IMHO, rather than some ad-hoc data access layer.