Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
Commercial support) In fact, now all databases +- work the same way - here it is worth looking at separate vendor-specific cases, so to speak. For most tasks, this monster is not needed.
Your question cannot be answered correctly. Each DBMS has its own architectural features and is essentially a platform, i.e. many useful things have already been implemented. Those. You can compare two specific DBMS and within the framework of solving a specific problem. As an enterprise IS DBMS, Oracle is a very good choice because usually in such systems the load is 50 to 50 (50 write \ 50 read). And due to the architectural features of Oracle (the implementation of transactions and locks), it copes with such exploitation with a bang. Plus, you still need to administer the database, take care of the safety of data after a failure (backup), a cloud of functions and objects for implementing business logic .... in short, a lot of things to do, and this is already implemented in Oracle. And as a bonus, Oracle is more tolerant of the hand-me-downs of developers who believe that all databases work and are the same. If there is a lot of data and you need to process it quickly, you can look towards Exadata. You can read more about the features in the documentation. And in everything else you need to look at a specific task. The biggest downside is the cost.
ZY: And on my own behalf, I will add, at the dawn of my career, I worked with MS SQL and hated this DBMS, just because of the implementations of transactions and locks, and the former developers helped me with this. In MS SQL, locks are row-level, but implemented in a common pool - a common pool of locks is minus speed (a common pool must be blocked to write or read these locks) and plus memory. And in order not to load the server too much, the previous developers implemented the logic in such a way that the process went through small transactions, of course with commits. And there were such precedents that the data was deleted, and they did not get into another table due to an error in the application. Then deadlocks, this is generally a separate issue, and it was necessary to resolve it by changing the data structure so that users would work only with their own data. In short, I remember it as a terrible dream. But when developing another IS where there was a decision to take Oracle as a DBMS, through the prism of past experience, it was a big discovery for me that there would not be such a hemorrhoids as with MS SQL. Of course, maybe MS SQL has changed a lot for the better now, but I still have a sediment.
Scalability to gigantic database sizes and gigantic number of requests. Important for big business.
At the same time, for small and medium-sized businesses, Oracle's disadvantages are much greater than its advantages. As long as any other DBMS can handle it, it's better to use that other DBMS. Oracle as a last resort, how to send Nimitz to war .
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question