6 ms·
> If it had been SQL it would have been easy to drop in another database. Not true at all. Way too many organisations are locked into Oracle just because it's
by geowwy 7y ago
> If it had been SQL it would have been easy to drop in another database.
Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.
- willio58 7y agoWhy is this? If Oracle uses SQL why can you not just export the database, make some transformations, and import it into a PostgreSQL db for example?
- peteretep 7y agoBecause Oracle uses Oracle's flavour of SQL, and no two databases are feature compatible.
- lsb 7y agoIf you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances! More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.
- deleted 7y ago[deleted]
- Spivak 7y agoI feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks. There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.
- goatinaboat 7y agoI think it is probably easier to port from one SQL dialect to another, than from Mongo’s hokey JSON based query language to anything else.
- statictype 7y agoAlso not easy. We tried to do a migration from Sql Server to Postgres. Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle. 1. Sql Server supports arbitrary sql statements in queries. Postgres does not. 2. Data types are not the same. 3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results. It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer. Also their API surface is relatively simple. For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.
- manojlds 7y agoIncluding Amazon, until recently.
- isubasinghe 7y agoWell there is pl/sql for instance that oracle has, migration costs would be too high for most people. We use pl/sql extensively at work, I cannot even imagine the effort(time/money/people) it would take to migrate from oracle.
- goto11 7y agoRelational/SQL databases still follow the same fundamental data model and query language, despite the differences in SQL syntax. I will argue migration is still easier. Just avoid stored procedures which complex logic, since these are essentially proprietary programming languages.
- statictype 7y agoEven without stored procedures, its not easy. To really take advantage of a database engine, you will probably end up using engine-specific idioms. Postgres and Sql Server support recursive CTEs. MySql probably doesn't? Sql Server supports cursors but is dog slow and generally not recommended for any sort of large scale operations. Isolation levels and locking are really important as well. Do all engines even support the same isolation levels?